Entity authentication in eletronic communications by providing verification status of device

ABSTRACT

A current verification status of a device ( 256 ) is identified out of a plurality of predefined verification data input ( 250 ) into the device ( 256 ) and data prestored within the device.( 254 ) The indicator ( 272 ) reveals neither the prestored data nor the verification data. One of the predefined verification statuses is representative of the verification data being the same as the prestored data, and another verification status is representative of the verification data being different from the prestored data. An identified verification status is used by one entity in determining risk regarding an electronic communication from another entity, especially where the electronic communication comprises a request. The prestored data is for a Secret or a biometric characteristic of the first entity.

I. CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This patent application claims priority in the United Statesunder 35 U.S.C. 119, and under the Paris Convention worldwide, to thebenefit of the filing date of Wheeler, et al. U.S. provisional patentapplication serial No. 60/223,076, which was filed on Aug. 4, 2000, andwhich is incorporated herein by reference. This application alsoincorporates herein by reference each of three international patentapplications and three U.S. patent application to Anne and Lynn Wheelerfiled concurrently herewith on Aug. 6, 2001, in the U.S. Patent &Trademark Office and bearing serial number PCT/US__/___ (entitled“Person-Centric Account-Based Digital Signature System”) and serialnumber 09/__,___, (entitled “Account-Based Digital Signature (ABDS)System”); serial number 09/__,___ (entitled “Modifying Message Data andGenerating Random Number Digital Signature Within Computer Chip”);serial number PCT/US__/___ (entitled “Linking Public Key of Device toInformation During Manufacture”) and Ser. No. 09/__,___ (entitled“Manufacturing Unique Devices That Generate Digital Signatures”); andserial number PCT/US__/___ (entitled “Trusted Authentication DigitalSignature (TADS) System”).

II. FIELD OF THE PRESENT INVENTION

[0002] The present invention generally relates to entity authenticationand, in particular, to entity authentication in the field of electroniccommunications.

III. BACKGROUND OF THE PRESENT INVENTION

[0003] As used herein, an electronic communication. (“EC”) is consideredto be any communication in electronic form. ECs have become an integralpart of transacting business today, especially with the growth of theInternet and e-commerce. An EC can represent, for example, a request foraccess to information or a physical area, a financial transaction, suchas an instruction to a bank to transfer funds, or a legal action, suchas the delivery of an executed contract.

[0004] Over recent years, digital signatures also have become animportant part of e-commerce. The origination of a digital signaturegenerally comprises: (1) the calculation of a message digest—such as ahash value; and (2) the subsequent encryption of the message digest. Themessage digest is encrypted by an electronic device generally using aprivate key of a key pair used in public-private key cryptography (alsoknown as asymmetric cryptography). The resulting ciphertext itselfusually constitutes the digital signature, which typically is appendedto the message to form the EC. The second part of originating thedigital signature—using encryption with a private key—is referred toherein as “generating” the digital signature, and the combined two stepsis referred to herein as “originating” the digital signature.Furthermore, while the generation of the digital signature isconventionally understood as the encryption of the message digest, it iscontemplated herein that generating the digital signature also mayinclude simply encrypting the message rather than the message digest.Digital signatures are important because any change whatsoever to themessage in an EC is detectable from an analysis of the message and thedigital signature. In this regard, the digital signature is used to“authenticate” a message contained within the EC (hereinafter referredto as “Message Authentication”).

[0005] For example, a message digest may be calculated by applying ahashing algorithm—such as the SHA-1 algorithm—to the message. Thehashing algorithm may be applied either within the device or external tothe device with the resulting hash value then being transmitted to thedevice for generation of the digital signature. In order to performMessage Authentication in this example, the recipient of the EC mustknow or be able to obtain both the identity of the hashing algorithmapplied to the message as well as the public key (“PuK”) correspondingto the private key used to encrypt the message digest. With thisknowledge, the recipient applies the appropriate hashing algorithm tothe message to calculate a hash value, and the recipient decrypts thedigital signature using the public key. If the hash value calculated bythe recipient equals the hash value of the decrypted digital signature,then the recipient determines that the content of the message containedin the EC was not altered in transmission, which necessarily would havechanged the hash value.

[0006] In performing Message Authentication, the recipient alsoauthenticates the sender of the EC, in so much as the recipient therebyconfirms that the sender of the EC possessed the private keycorresponding to the public key used successfully to authenticate themessage. This is one type of entity authentication and is based on whatthe sender “has” (hereinafter referred to as “Factor A EntityAuthentication”). Factor A Entity Authentication is useful when therecipient of the EC has trusted information regarding the identity ofthe owner of the private key. Such trusted information may arise from adigital certificate issued by a trusted third party that accompanies theEC and binds the identity of the private key owner with the public key.This trusted knowledge also may comprise actual knowledge of theidentity of the private key owner, such as in the case where therecipient itself has issued the private key or device containing theprivate key to the owner.

[0007] As will be appreciated, trust in the digital signature systemdepends upon the legitimate possession and use of the private key, i.e.,upon the sender of the EC actually being the private key owner. Afraudulent use of a private key to generate a digital signature of an ECcurrently cannot be detected through the above-described MessageAuthentication and Factor A Entity Authentication procedures. Thedigital signature system therefore is susceptible to fraud if a privatekey of a device is stolen, either by discovery of the private keytherein and subsequent copying and use in another device capable ofgenerating digital signatures, or by physical theft of the devicecontaining the private key.

[0008] To guard against discovery of a private key and subsequentcopying and use in another device, devices are manufactured withelectronic shielding, zeroization, auditing, tamper evidence and tamperresponse, and other security features that safeguard the private key(and other protected data) contained therein. Such security featuresinclude hardware, software, and firmware and are well known in the artof manufacturing secure computer chips and other devices havingcryptographic modules.

[0009] The requirements of such security features are specified, forexample, in Federal Information Processing Standards Publication 140-1,Security Requirements for Cryptographic Modules, US DOC/NBS, Jan. 11,1994 (herein “FIPS PUB 140-1”), which is incorporated herein byreference and which is available for download athttp://csrc.nist.gov/publications/fips; and Federal InformationProcessing Standards Publication 140-2, Security Requirements forCryptographic Modules, US DOC/NBS, May 25, 2001 (herein “FIPS PUB140-2”), which is incorporated herein by reference and which isavailable for download at http://csrc.nist.gov/publications/fips. FIPSPUB 140-1 and 140-2 also define security levels that may be met by adevice based on the device's security features, with each of thesedefined security levels generally representing a various level ofdifficulty—in terms of time and money—that would be encountered inattempting to discern a private key of a device. Currently, foursecurity levels are defined with security level 4 being the highestlevel of security available.

[0010] Specifications for such security features also are set forth inTrusted Computing Platform Alliance Trusted Platform Module ProtectionProfile Version 0.45, TRUSTED COMPUTING PLATFORM ALLIANCE, September2000; Trusted Platform Module (TPM) Security Policy Version 0.45,TRUSTED COMPUTING PLATFORM ALLIANCE, October 2000; and TCPA PCImplementations Specification Version 0.95, TRUSTED COMPUTING PLATFORMALLIANCE, July 4, 2001, which are incorporated herein by reference(collectively “TCPA Documents”), and which are available for download athttp://www.trustedpc.com; and Common Criteria for Information TechnologySecurity Evaluation, Smart Card Protection Profile, Draft Version 2.1d,SMART CARD SECURITY USER GROUP, March 21, 2001, which is incorporatedherein by reference (hereinafter “Smart Card Protection Profile”), andwhich is available for download at http://csrc.nist.gov.

[0011] To guard against fraudulent use of a device through theft of thedevice itself, a personal identification number (PIN), password, orpassphrase (collectively referred to herein as “Secret”) is typicallyprestored within the device and must be input into the device before itwill operate to generate digital signatures. Alternatively, the Secretis shared with the recipient beforehand and, when the EC later is sentto the recipient, the Secret also is sent to the recipient inassociation with the message. In the first case, verification of theSecret authenticates the user of the device (hereinafter “UserAuthentication”), and in the second case, verification of the Secretauthenticates the sender of the EC (hereinafter “SenderAuthentication”). In either case, confirmation of the Secret representsentity authentication based on what the user or sender “knows”(hereinafter “Factor B Entity Authentication”).

[0012] Another countermeasure against fraudulent use of the devicethrough physical theft includes the verification of a biometriccharacteristic—like a fingerprint—of the user of the device or sender ofthe EC. This type of authentication is based on what the user or sender“is” (hereinafter “Factor C Entity Authentication”). As with the Secret,a biometric value is either maintained within the device for UserAuthentication, or is shared with the recipient beforehand for SenderAuthentication by the recipient.

[0013] While Factor B Entity Authentication and Factor C EntityAuthentication both reduce the risk of a fraudulent use of a device togenerate a digital signature for a message, both also includesignificant drawbacks. For instance, if the Secret or biometric value iscommunicated to the recipient in association with a message for senderauthentication by the recipient, then the Secret or biometric valuefirst must have been shared with the recipient beforehand andsafeguarded by the recipient as part of an established relationship.This conventional paradigm therefore precludes both Factor B EntityAuthentication and Factor C Entity Authentication between entitieshaving no such preexisting relationship.

[0014] This paradigm also exposes the Secret or biometric value itselfto a greater risk of theft. First, the transmission of the Secret orbiometric value for verification carries with it the risk ofinterception and discovery during transit. Second, the Secret orbiometric value must be safeguarded by the recipient, thereby exposingthe Secret to theft from the recipient. This is especially significantin the corporate context where a rogue employee may steal thesafeguarded Secret or biometric value (insider fraud historically hasbeen the greatest risk).

[0015] The potential damages also are extensive when the Secret orbiometric value is stolen under this paradigm. Since it is difficult foran individual to remember multiple Secrets for multiple recipients, itis common for the same Secret to be used by an individual with differentrecipients. For example, with regard to credit cards, the same Secretusually is shared with all credit card companies as a matter ofconvenience, and usually comprises the mother's maiden name of theaccount holder. The theft of the Secret from one credit card companyputs all of the other credit card accounts at jeopardy, at least untilthe Secret is changed. In the case of the theft of a biometric value,the damages are even more severe, as a person's biometric characteristiccannot be changed and, once lost, potentially compromises any futureentity authentication therewith.

[0016] Alternatively, when the Secret or biometric value is prestoredand maintained within the device for User Authentication, the risksassociated with safeguarding of the Secret or biometric value by therecipient and associated with transmission of the Secret or biometricvalue to the recipient are avoided. In this conventional paradigm, therecipient does not actually perform the verification—it is done at thedevice level.

[0017] A drawback to this alternative paradigm, however, is that becausethe device remains inoperable until the correct Secret or biometricvalue of the user is entered, the recipient is unable to monitorrepeated attempts to guess the Secret or biometric value. Furthermore,when the device is enabled by the entry of the correct Secret or abiometric value resulting in a match, the device typically remainsenabled for a predefined period of time thereafter, such as until it ispowered off or resets. Under this alternative paradigm, a recipient isunable to determine whether a particular EC sent during such a timeperiod includes a fraudulently generated digital signature, as thedevice may have been stolen after being enabled but before itsdeactivation. Accordingly, while there is User Authentication under thisalternative paradigm, there is no provision per se for SenderAuthentication.

[0018] Yet another drawback is that this alternative paradigm does notparticularly accommodate the use of the device to send ECs to differentrecipients when a biometric value is prestored and maintained within—andFactor C Entity Authentication is performed by—the device. In thisregard, different recipients may have different requirements as to whatconstitutes a biometric “match” so as to be a successful verification; abiometric match is a determination of whether a biometric value input issufficiently close to a stored biometric value so as to meet at least aminimum security threshold. A security threshold is subjectively set byeach recipient and includes factors such as the nature of thecommunication and the extent of liability to the recipient for actionsand responses based on a fraudulently sent EC. Different recipientscannot make their own match/no-match determinations based on their ownrequirements, standards, and criteria if each recipient does not receivebeforehand the biometric value of the sender, make its own comparisonthereof with each additional biometric value that is received inassociation with a message, and apply its own business judgment as towhether the comparison is sufficiently close so as to be a match.

[0019] Accordingly, a need exists for a new paradigm in which Factor BEntity Authentication and/or Factor C Entity Authentication is used, butin which the aforementioned drawbacks of the conventional paradigms thatuse such authentication procedures are overcome. In particular, a needexists for such a paradigm that provides for both User Authentication aswell as for Sender Authentication using either or both of Factor BEntity Authentication and Factor C Entity Authentication, and allwithout requiring a recipient to safeguard either a Secret or abiometric value. In this regard, a need exists for such a paradigm inwhich Factor B Entity Authentication and Factor C Entity Authenticationcan be reliably inferred by the recipient without the recipient beingprivy to the authenticating information, thereby addressing privacyconcerns. Furthermore, a need exists in such a paradigm for therecipient to be able to determine, in its own subjective businessjudgment, what constitutes a successful biometric match when Factor CEntity Authentication is used. A need also exists for such a paradigm inwhich the recipient is able to monitor repeated attacks on a device toguess a Secret or a biometric value, and for such a paradigm thatfurther accommodates the use of a single device for the sending of ECsto various, unrelated recipients.

IV. SUMMARY OF THE PRESENT INVENTION

[0020] A. First Aspect of the Present Invention

[0021] A first aspect of the present invention relates to the provisionof a verification status of a device and includes the steps ofidentifying within the device a current verification status out of aplurality of predefined verification statuses of the device as afunction of verification data input into the device and data prestoredwithin the device; and, independent of the verification statusidentified, transmitting the identified verification status to anelectronic apparatus external to the device. One of the predefinedverification statuses is representative of the verification data beingthe same as the prestored data, and at least one other verificationstatus is representative of the verification data being different fromthe prestored data. An indicator of the identified verification statusis output from the device.

[0022] In a variation of this aspect of the invention, the verificationstatus regards an entity authentication using a device. This variationincludes the steps of receiving within the device input comprisingverification data of an entity; identifying within the device a currentverification status out of a plurality of predefined verificationstatuses of the device as a function of the verification data and dataprestored within the device; and, independent of the verification statusidentified, outputting from the device an indicator of the identifiedverification status. Again, one of the predefined verification statusesbeing representative of the verification data being the same as theprestored data, and at least one other verification status beingrepresentative of the verification data being different from theprestored data.

[0023] In another variation, a first entity is authenticated to a secondentity. In this variation, data of the first entity is stored within averification component of a device during a personalization of theverification component. Later, verification data is input into thedevice and received within the verification component of the device, anda current verification status is identified as a function of theverification data and prestored data within the verification componentof the device. The verification status identified is one out of aplurality of predefined verification statuses of the device that includea verification status representative of the verification data being thesame as the prestored data, and at least one other verification statusrepresentative of the verification data being different from theprestored data. Independent of the verification status identified, suchverification status is communicated to the second entity. Theverification status is communicated to the second entity by outputtingan indicator of the verification status from the verification componentand transmitting the output indicator to the second entity.

[0024] In a fourth variation of this aspect of the present invention, averification status regarding an entity authentication is providedwherein no verification data is yet received by a device. In particular,the method in this case includes the steps of maintaining within thedevice prestored data of an entity for identifying a verification statusof the device as a function of the prestored data and verification datalater input into the device; identifying within the device a currentverification status of the device representing the lack of input of anyverification data during a predefined period of time; and outputtingfrom the device an indicator of the identified verification status forevaluation thereof. Preferably at some point thereafter, inputcomprising verification data is received within the device, a currentverification status is identified within the device out of a pluralityof predefined verification statuses of the device by comparing thereceived verification data with the prestored data; and an indicator ofthe identified verification status is again output from the device forevaluation thereof, wherein the second indicator reveals the identifiedverification status based on the comparison. Preferably, oneverification status out of the plurality of predefined verificationstatuses of the device is representative of the verification data beingthe same as the prestored data, and at least one other predefinedverification status is representative of the verification data beingdifferent from the prestored data.

[0025] In preferred embodiments of this aspect of the present invention:the prestored data represents either a Secret or biometriccharacteristic, or both; the verification status identified as thecurrent verification status represents a relational correspondencebetween the verification data and the prestored data without revealingeither of the verification data or the prestored data; and the device iscapable of generating digital signatures. Additionally, a request isevaluated with business logic based on the identified verificationstatus.

[0026] B. Second Aspect of the Present Invention

[0027] A second aspect of the present invention relates to the provisionof a verification status of a device and includes the steps ofidentifying within the device a current verification status out of aplurality of predefined verification statuses of the device as afunction of biometric verification data input into the device andbiometric data prestored within the device; and, independent of theverification status identified, transmitting an indicator of theidentified verification status to an electronic apparatus external tothe device, the indicator revealing the identified verification statuswithout revealing either of the verification data or the prestored data.The indicator of the identified verification status is output from thedevice.

[0028] In a variation of this aspect of the invention, the verificationstatus regards an entity authentication using the device. This variationincludes the steps of receiving within the device input comprisingbiometric verification data of an entity; identifying within the devicea current verification status out of a plurality of verificationstatuses of the device as a function of the verification data andbiometric data prestored within the device; and, independent of theverification status identified, outputting from the device an indicatorof the identified verification status, the indicator revealing theidentified verification status without revealing either of theverification data or the prestored data.

[0029] In another variation, a first entity is authenticated to a secondentity. In this variation, biometric data of the first entity is storedwithin a verification component of a device during a personalization ofthe verification component. Later, biometric verification data is inputinto the device and received within the verification component of thedevice, and a current verification status is identified as a function ofthe verification data and prestored data within the verificationcomponent of the device. Independent of the verification statusidentified, such verification status is communicated to the secondentity by outputting from the verification component an indicator of theidentified verification status and transmitting the output indicator tothe second entity. The indicator reveals the identified verificationstatus without revealing either of the verification data or theprestored data.

[0030] In a fourth variation of this aspect of the present invention, averification status regarding an entity authentication is providedwherein no verification data is yet received by a device. In particular,the method in this case includes the steps of maintaining within thedevice prestored biometric data of an entity for identifying averification status of the device as a function of the prestored dataand biometric verification data later input into the device; identifyingwithin the device a current verification status of the devicerepresenting the lack of input of any verification data during apredefined period of time; and outputting from the device an indicatorof the identified verification status for evaluation thereof. Preferablyat some point thereafter, input comprising verification data is receivedwithin the device, a current verification status is identified withinthe device out of a plurality of predefined verification statuses of thedevice by comparing the received verification data with the prestoreddata; and an indicator of the identified verification status is againoutput from the device for evaluation thereof, wherein the secondindicator reveals the identified verification status based on thecomparison without revealing either of the verification data or theprestored data.

[0031] In preferred embodiments of this aspect of the present invention:one verification status out of the plurality of predefined verificationstatuses of the device is representative of the verification data beingthe same as the prestored data, and at least one other predefinedverification status is representative of the verification data beingdifferent from the prestored data; and the device is capable ofgenerating digital signatures. Additionally, a request is evaluated withbusiness logic based on the identified verification status.

[0032] C. Third Aspect of the Present Invention

[0033] A third aspect of the present invention relates to the provisionof a verification status of a device and includes the steps ofidentifying within the device a current verification status out of aplurality of predefined verification statuses of the device; generatingwithin the device a digital signature for a message as a function of theidentified verification status, including modifying within the devicedata representing the message as a function of the identifiedverification status of the device such that the generated digitalsignature comprises an indicator of the identified verification status;and, transmitting the generated digital signature to an electronicapparatus external to the device. The identification of the currentverification status is a function of verification data input into thedevice and data prestored within the device.

[0034] In a variation of this aspect of the invention, the verificationstatus regards an entity authentication. This variation includes thesteps of receiving within the device input comprising verification dataof an entity; identifying within the device a current verificationstatus out of a plurality of predefined verification statuses of thedevice as a function of the verification data and data prestored withinthe device; generating within the device a digital signature for amessage as a function of the identified verification status, includingmodifying within the device data representing the message as a functionof the identified verification status of the device such that thegenerated digital signature comprises an indicator of the identifiedverification status; and outputting from the device the generateddigital signature.

[0035] In another variation, a first entity is authenticated to a secondentity. In this variation, data of the first entity is stored within averification component of a device during a personalization of theverification component. Later, verification data is input into andreceived within the verification component of the device, and a currentverification status is identified as a function of the verification dataand prestored data within the verification component of the device. Theverification status identified is one out of a plurality of predefinedverification statuses of the device. A digital signature then isgenerated within the device for a message as a function of theidentified verification status and includes modifying within the devicedata representing the message as a function of the identifiedverification status of the device. The generated digital signaturecomprises an indicator of the identified verification status. Thedigital signature is output from the verification component of thedevice and, thereafter, communicated to the second entity.

[0036] In a fourth variation of this aspect of the present invention, averification status regarding an entity authentication is providedwherein no verification data is yet received by a device. In particular,the method in this case includes the steps of maintaining within thedevice prestored data of an entity for identifying a verification statusof the device as a function of the prestored data and verification data,later input into the device; identifying within the device a currentverification status of the device representing the lack of input of anyverification data during a predefined period of time; generating withinthe device a digital signature for a message such that the generateddigital signature comprises an indicator of the identified verificationstatus; and outputting from the device the generated digital signaturefor evaluation of the identified verification status. Preferably at somepoint thereafter, input comprising verification data is received withinthe device; a current verification status is identified within thedevice out of a plurality of predefined verification statuses of thedevice by comparing the received verification data with the prestoreddata; and another digital signature is generated within the device for amessage as a function of the identified verification status. In thisregard, data representing the message is modified within the device as afunction of the identified verification status of the device. The,second generated digital signature comprising an indicator of theidentified verification status is then output from the device forevaluation thereof.

[0037] In preferred embodiments of this aspect of the present invention,one verification status out of the plurality of predefined verificationstatuses of the device is representative of the verification data beingthe same as the prestored data, and at least one other predefinedverification status is representative of the verification data beingdifferent from the prestored data; the indicator of the identifiedverification status neither reveals the prestored data nor theverification data; the prestored data represents a Secret; and theprestored data represents a biometric characteristic. Additionally, arequest is evaluated with business logic based on the identifiedverification status.

[0038] The generation of the digital signature includes encryptingwithin the device using a private key of a public private key pair amessage digest calculated within the device for the modified data. In apreferred embodiment, the digital signature for the modified datarepresenting the message is output from the device, but the modifieddata itself is not output from the device.

[0039] In some preferred embodiments, the message is composed within thedevice by a user of the device. Preferably, the message for which adigital signature is generated is displayed on a display screen of thedevice for review and approval by the user. Alternatively, the messageis composed within an I/O support element external to the device which,in turn, transmits the input representing the message into the devicethrough an interface of the device. In other preferred embodiments, aportion of the message is composed within an I/O support elementexternal to the device which, in turn, transmits input representing theportion of the message into the device through an interface of thedevice, and a remaining portion of the message is composed within thedevice. The I/O support element may comprise, for example, a point ofsale terminal, a biometric scanner, a card reader, or a computer.

[0040] The message itself may be for the performance of a financialtransaction, the performance of a legal action, access to a database,access to a physical space, access to a web site, or access to acomputer program. The message also may be predetermined and static, andmay be stored within the device itself. Verification data also may notbe required to be input into the device for other types of messages, orfor a predefined period of time such as the time between approval of arequest embodied in a message and a powering off of the device.

[0041] The data representing the message comprise a hash value of themessage or, alternatively, the data representing the message comprise amessage digest for the message. The data representing the message may bestored within the device. The modification of the data representing themessage preferably includes: embedding the assigned value of anidentification marker within the data representing the message;appending the assigned value of the identification marker t o the datarepresenting the message; appending the assigned value of theidentification marker to the beginning of the data representing themessage; and appending the assigned value of the identification markerto the end of the data representing the message.

[0042] In preferred embodiments, verification data may be required to beinput into the device following a predefined period of time after a lastsuccessful verification, and verification data may be required to beinput into the device for each one of a particular type of message. Theparticular type of message may comprise, for example, a request for afinancial transaction.

[0043] Additional preferred embodiments include message authenticationusing the digital signature generated within the device, and include thesteps of: modifying data representing the message embodying the requestas a function of a suspected verification status of the device,calculating a message digest as a function of the modified data,decrypting the generated digital signature using the public key of thepublic-private key pair, and concluding the verification status of thedevice as being the suspected verification status of the device when thecalculated message digest matches the decrypted digital signature.

[0044] The device preferably identifies the current verification statusof the device by assigning an identification marker within the deviceequal to a value out of a set of predefined values corresponding to thepredefined verification statuses. In a preferred embodiment, theidentification marker is assigned a value equated with a successfulverification, and the assigned value further represents whether adigital signature was generated since verification data was last inputinto the device. Furthermore, the generated digital signature preferablycomprises the indicator.

[0045] D. Fourth Aspect of the Present Invention

[0046] A fourth aspect of the present invention relates to the provisionof a verification status of a device and includes the step ofidentifying within the device a current verification status out of aplurality of predefined verification statuses of the device as afunction of verification data input into the device and data prestoredwithin the device. This step includes comparing verification datarepresenting a Secret with the data prestored within the device andassigning, based on the comparison, a first comparison marker within thedevice equal to a value out of a set of predefined values; and comparingverification data representing biometric data with the data prestoredwithin the device and assigning, based on the comparison, a secondcomparison marker within the device equal to a value out of a set ofpredefined values. Data representing a message is modified within thedevice as a function of the assigned values for the first and secondcomparison markers. Thereafter, a digital signature is generated withinthe device for the modified data such that the generated digitalsignature comprises an indicator of the identified verification status.The generated digital signature then is transmitted to an electronicapparatus external to the device.

[0047] In a variation of this aspect of the invention, the verificationstatus regards an entity authentication using a device. This variationincludes the steps of receiving within the device input comprisingverification data of an entity, the verification data representing botha Secret and a biometric characteristic of the entity; identifyingwithin the device a current verification status out of a plurality ofpredefined verification statuses of the device as a function of theverification data and data prestored within the device; modifying withinthe device data representing a message as a function of the identifiedverification status and generating within the device a digital signaturefor a message such that the generated digital signature comprises anindicator of the identified verification status; and outputting from thedevice the generated digital signature. The identification of theverification status includes comparing verification data representingthe Secret with the data prestored within the device and assigning,based on the comparison, a first comparison marker within the deviceequal to a value out of a set of predefined values; and comparingverification data representing biometric data with the data prestoredwithin the device and assigning, based on the comparison, a secondcomparison marker within the device equal to a value out of a set ofpredefined values. The modification of the message data includesmodifying the data as a function of the assigned values for the firstand second comparison markers.

[0048] In another variation, a first entity is authenticated to a secondentity. In this variation, data representing both a Secret and biometricdata of the first entity is stored within a verification component of adevice during a personalization of the verification component. Later,verification data is input into the device and received within theverification component of the device, and a current verification statusis identified as a function of the verification data and prestored datawithin the verification component of the device. The identification ofthe verification status includes comparing verification datarepresenting the Secret with data prestored within the device andassigning, based on the comparison, a first comparison marker within thedevice equal to a value out of a set of predefined values; and comparingverification data representing biometric data with data prestored withinthe device and assigning, based on the comparison, a second comparisonmarker within the device equal to a value out of a set of predefinedvalues. A digital signature is generated within the device for a messageby first modifying within the device data representing the message as afunction of the assigned values for the first and second comparisonmarkers, and then encrypting the modified data such that the digitalsignature comprises an indicator of the identified verification status.The digital signature then is output from the verification component andtransmitted to the second entity.

[0049] In preferred embodiments of this fourth aspect of the presentinvention: one verification status out of the plurality of predefinedverification statuses of the device is representative of theverification data being the same as the prestored data, and at least oneother predefined verification status is representative of theverification data being different from the prestored data; the assignedvalue of the first comparison marker, the assigned value of the secondcomparison marker, or the assigned values of the first and secondcomparison markers are output from the device with the generated digitalsignature; and the modification of the message includes embedding theassigned value of the first comparison marker, the assigned value of thesecond comparison marker, or both, within the data representing themessage, or appending such assigned value(s) to the data representingthe message, including appending to the beginning or the end of themessage data. Additionally, a request is evaluated with business logicbased on the identified verification status.

[0050] In alternative embodiments to this fourth aspect of the presentinvention, the data representing the message is modified as a functionof only one of the assigned values for the first and second comparisonmarkers. Furthermore, the generated digital signature for the messageand the other of the assigned values for the first and second comparisonmarkers is transmitted to the second entity.

[0051] E. Fifth Aspect of the Present Invention

[0052] A fifth aspect of the present invention relates to determining acurrent verification status of a device that generates a digitalsignature and includes the steps: receiving a digital signature;decrypting the digital signature using a public key of a public-privatekey pair; for each one of a plurality of predefined verificationstatuses of the device, modifying data representing a message as afunction of the predefined verification status; and identifying thecurrent verification status of the device as being the predefinedverification status for which the modified data matches the decrypteddigital signature. In a variation of this aspect, a message digest iscalculated as a function of the modified data following themodification. The calculation of the message digest as a function of themodified data may include the calculation of a hash value for themodified data.

[0053] In preferred embodiments of this fourth aspect of the presentinvention, each one of the verification statuses represents a relationalcorrespondence between verification data input into the device and dataprestored within the device. Furthermore, each verification statusneither reveals verification data nor prestored data of the device forwhich the current verification status is determined.

[0054] Preferably, the current verification status is associated with arequest. The request, for example, may be for the performance of afinancial transaction or for the performance of a legal action. Therequest, for example, may be predetermined and static and included in apredefined message. The request may be for access to a physical space,access to a web site, access to a database, or access to a computerprogram. Preferably, the request is received in association with thedigital signature and evaluated based on the current verification statusindicated by the digital signature. The evaluation of the requestincludes the step of considering an assurance level of the devicegenerating the digital signature. The request may be implicit in thereceipt of the digital signature. The request may be communicated overan electronic communications medium such as a computer network, whetherpublic or private.

[0055] Additionally, in preferred embodiments, one of the predefinedverification statuses represents an unsuccessful verification; one ofthe predefined verification statuses represents a successfulverification; one of the predefined verification statuses additionallyrepresents whether a digital signature has been generated by the devicesince verification data was last input into the device; one of thepredefined verification statuses additionally represents whether adigital signature has been generated subsequent to a comparison ofverification data input into the device with data prestored within thedevice; one of the predefined verification statuses additionallyrepresents whether any verification data has been input into the devicewithin a predetermined time period comprising, for example, the timesince a last successful verification or the time since a resetting ofthe device.

[0056] Additionally, in preferred embodiments, one of the predefinedverification status represents a difference between verification datainput into the device and data prestored within the device; one of thepredefined verification statuses represents a degree of match betweenbiometric verification data input into the device and biometric dataprestored within the device; one of the predefined verification statusesadditionally represents a percentage of match between biometricverification data input into the device and biometric data prestoredwithin the device; one of the predefined verification statusesadditionally represents whether a digital signature has been generatedby the device since verification data was last input into the device;one of the predefined verification statuses additionally representswhether a digital signature has been generated subsequent to acomparison of verification data input into the device with dataprestored within the device; one of the predefined verification statusesadditionally represents whether any verification data has been inputinto the device within a predetermined time period.

[0057] F. Features of the Present Invention

[0058] In features of the aforementioned aspects of the presentinvention, the device preferably identifies the current verificationstatus of the device by assigning an identification marker within thedevice equal to a value out of a set of predefined values correspondingto the predefined verification statuses. In preferred embodiments, theidentification marker is assigned a value equated with a successfulverification when the comparison results in a match, including an exactmatch (e.g., when the data represents a Secret); the identificationmarker is assigned a value equated with a successful verification whenthe comparison results in a match, but not an exact match (e.g., whenthe data represents a biometric characteristic); and, the identificationmarker is assigned a value equated with an unsuccessful verificationwhen a comparison between the verification data and the prestored datadoes not result in a match.

[0059] Additionally in preferred embodiments, the identification markeris assigned a value representing a difference determined from acomparison between the verification data and the prestored data; theidentification marker is assigned a value representing a degree of matchbetween the verification data and the prestored data; the identificationmarker is assigned a value equated with a percentage, of match betweenthe verification data and the prestored data; and the identificationmarker is assigned a value representing whether any verification datawas input into the device within a predefined time period, such as thetime since a last successful verification or the time since a resettingof the device.

[0060] In preferred embodiments wherein the identification marker isassigned a value equated with a successful verification, the assignedvalue further represents whether an indicator was output subsequent tothe successful verification or whether an indicator was output sinceverification data was last input into the device. In additionalfeatures, the indicator comprises the assigned value of theidentification marker, and the assigned value further represents whethera digital signature was generated by the device since verification datawas last input into the device. Furthermore, the device preferablygenerates a digital signature in response to an external inquiryreceived by the device, in response to receipt of data representing themessage, or in response to receipt of input comprising the verificationdata.

[0061] Other features of the present invention include the verificationdata being input directly into the device by a user; and, alternatively,input representing the verification data being received within an I/Osupport element external to the device and then transmitted into thedevice. The I/O support element may include, for example, a point ofsale terminal, a biometric scanner, a card reader, an ATM machine, or acomputer.

[0062] In yet additional features, the indicator points definitively(i.e., without ambiguity) to a single predefined verification status ofthe device; neither the prestored data comprising a Secret and/orbiometric data nor the verification data input into the device areexported from the device; and the device prestores data for a pluralityof users of the device; a digital signature is generated within thedevice and output from the device with the value of the identificationmarker.

[0063] When the prestored data comprises biometric data, theidentification marker is assigned a value representing the type of thebiometric data in a feature of the present invention. Furthermore, thebiometric data may represent, for example, a digitized fingerprint, adigitized handprint or hand geometry, a digitized retina, a digitizediris, a digitized voice print, a digitized facial scan, a digitizedwritten signature, or a digitized DNA sample. In such case, the devicemay include a biometric scanner for inputting of the verification data.The device also may prestore data for a plurality of different types ofbiometric data, whether for one person or for several persons.

[0064] In other features of the present invention wherein a request isevaluated based on the identified verification status, verification datais required to be input into the device for each one of a particulartype of request such as, for example, a financial transaction.Verification data may not be required to be input into the device forother types of requests. Verification data also may be required to beinput into the device for a particular type of request, but only untilan evaluation of the request results in an approval, and thenverification data may not be required to be input into the device foradditional requests of such type during a predefined period of timethereafter, such as the time between the approval of the request and aresetting of the device.

[0065] Random numbers are utilized in may computer applications, such asin security protocols like secure socket layer (SSL) protocol and prettygood privacy (PGP) for the creation of session keys. Yet another featureof the present invention includes the generation of a digital signatureusing a digital signature algorithm, with the resulting digitalsignature being used in such an application as a random number.

[0066] The device of the methods of the present invention preferably isa personal device of the sender of the EC. The device also preferablyincludes a device interface such as, for example, an alphanumerickeypad, an electrical contact, a touch screen display, a standardelectronic interface with a computer bus, or an antenna. The deviceinterface also may comprise a port the device, such as a wirelesscommunications port, a serial port, a USB port, a parallel port, or aninfrared port. The device preferably is portable and of a handheld formfactor. The device preferably includes a computer chip and/or integratedcircuitry, and may be, for example, a cell phone, a PDA, a digitizedkey, a dongle, a subcutaneous implant, jewelry, an integrated circuitcard (IC Card), a credit card, a debit card, smart card, a securitycard, an ID badge, or a computer.

[0067] Other features of the present invention include: a device with acomputer-readable medium having computer-executable instructions thatperform one or more steps of a method of the present invention;integrated circuitry that performs one or more steps of a method of thepresent invention; and a computer chip that performs one or more stepsof a method of the present invention.

V. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] Benefits and further features of the present invention will beapparent from a detailed description of preferred embodiments thereoftaken in conjunction with the following drawings, wherein like referencenumbers refer to like elements, and wherein:

[0069]FIG. 1 illustrates in block diagram a conceptual framework of thepresent invention;

[0070]FIG. 2a illustrates a first preferred embodiment of the presentinvention;

[0071]FIG. 2b illustrates a variation of the embodiment of FIG. 2a;

[0072]FIG. 2c illustrates a variation of the embodiment of FIG. 2a;

[0073]FIG. 3 illustrates a preferred mode of operation of the device ofFIGS. 2a, 2 b, and 2 c;

[0074]FIG. 4a illustrates a second preferred embodiment of the presentinvention;

[0075]FIG. 4b illustrates a variation of the embodiment of FIG. 4a;

[0076]FIG. 4c illustrates a variation of the embodiment of FIG. 4a;

[0077]FIG. 5 illustrates a preferred mode of operation of the device ofFIGS. 4a, 4 b, and 4 c;

[0078]FIG. 6a illustrates a third preferred embodiment of the presentinvention;

[0079]FIG. 6b illustrates a variation of the embodiment of FIG. 6a;

[0080]FIG. 6c illustrates a variation of the embodiment of FIG. 6a;

[0081]FIG. 7 illustrates a preferred mode of operation of the device ofFIGS. 6a, 6 b, and 6 c;

[0082]FIG. 8a illustrates a fourth preferred embodiment of the presentinvention;

[0083]FIG. 8b illustrates a variation of the embodiment of FIG. 8a;

[0084]FIG. 8c illustrates a variation of the embodiment of FIG. 8a;

[0085]FIG. 8d illustrates a variation of the embodiment of FIG. 8a;

[0086]FIG. 9 illustrates a preferred mode of operation of the device ofFIGS. 8a, 8 b, and 8 c;

[0087]FIG. 10a illustrates a fifth preferred embodiment of the presentinvention;

[0088]FIG. 10b illustrates a variation of the embodiment of FIG. 10a;

[0089]FIG. 10c illustrates a variation of the embodiment of FIG. 10a;

[0090]FIG. 11 illustrates a preferred mode of operation of the device ofFIGS. 10a, 10 b, and 10 c;

[0091]FIG. 12a illustrates a sixth preferred embodiment of the presentinvention;

[0092]FIG. 12b illustrates a variation of the embodiment of FIG. 12a;

[0093]FIG. 12c illustrates a variation of the embodiment of FIG. 12a;

[0094]FIG. 13 illustrates a preferred mode of operation of the device ofFIGS. 12a, 12 b, and 12 c;

[0095]FIG. 14a illustrates a seventh preferred embodiment of the presentinvention;

[0096]FIG. 14b illustrates a variation of the embodiment of FIG. 14a;

[0097]FIG. 14c illustrates a variation of the embodiment of FIG. 14a;

[0098]FIG. 15 illustrates a preferred mode of operation of the device ofFIGS. 14a, 14 b, and 14 c;

[0099]FIG. 16a illustrates an eighth preferred embodiment of the presentinvention;

[0100]FIG. 16b illustrates a variation of the embodiment of FIG. 16a;

[0101]FIG. 16c illustrates a variation of the embodiment of FIG. 16a;

[0102]FIG. 17 illustrates a preferred mode of operation of the device ofFIGS. 16a, 16 b, and 16 c;

[0103]FIG. 18a illustrates a ninth preferred embodiment of the presentinvention;

[0104]FIG. 18b illustrates a variation of the embodiment of FIG. 18a;

[0105]FIG. 18c illustrates a variation of the embodiment of FIG. 18a;

[0106]FIG. 19 illustrates a preferred mode of operation of the device ofFIGS. 18a, 18 b, and 18 c;

[0107]FIGS. 20a, 20 b, and 20 c illustrate preferred formats ofprestored data of the present invention;

[0108]FIGS. 21a, 21 b, and 21 c illustrate preferred formats ofverification data of the present invention;

[0109]FIG. 22 illustrates a preferred comparison and verification statusidentification process;

[0110]FIGS. 23a and 23 b illustrate preferred comparison andverification status identification processes;

[0111]FIG. 24 illustrates a preferred comparison and verification statusidentification process;

[0112]FIGS. 25a and 25 b illustrate preferred formats of identificationmarkers of the present invention;

[0113]FIG. 26 illustrates preferred formats of identification markers ofthe present invention;

[0114]FIG. 27 illustrates a table of identification markers resultingfrom a hypothetical sequence of verification data inputs in accordancewith the present invention;

[0115]FIG. 28 illustrates a preferred data flowchart within animplementation of the present invention using a computer chip;

[0116]FIG. 29 illustrates a first specific implementation of the presentinvention using an IC card;

[0117]FIG. 30 illustrates a second specific implementation of thepresent invention using an IC card;

[0118]FIG. 31 illustrates a third specific implementation of the presentinvention using an IC card;

[0119]FIGS. 32a and 32 b illustrate fourth and fifth specificimplementations of the present invention using an IC card; and

[0120]FIG. 33 illustrates a sixth specific implementation of the presentinvention using an IC card.

VI. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0121] As a preliminary matter, it readily will be understood by thosepersons skilled in the art that, in view of the following detaileddescription of the devices, systems, and methods of the presentinvention, the present invention is susceptible of broad utility andapplication. Many embodiments and adaptations of the present inventionother than those herein described, as well as many variations,modifications, and equivalent arrangements, will be apparent from orreasonably suggested by the present invention and the following detaileddescription thereof, without departing from the substance or scope ofthe present invention. Furthermore, those of ordinary skill in the artwill understand and appreciate that although steps of various processesmay be shown and described in some instances as being carried out in apreferred sequence or temporal order, the steps of such processes arenot necessarily to be limited to being carried out in such particularsequence or order. Rather, in many instances the steps of processesdescribed herein may be carried out in various different sequences andorders, while still falling within the scope of the present invention.Accordingly, while the present invention is described herein in detailin relation to preferred embodiments, it is to be understood that thisdetailed description only is illustrative and exemplary of the presentinvention and is made merely for purposes of providing a full andenabling disclosure of the present invention. The detailed descriptionset forth herein is not intended nor is to be construed to limit thepresent invention or otherwise to exclude any such other embodiments,adaptations, variations, modifications and equivalent arrangements ofthe present invention, the present invention being limited solely by theclaims appended hereto and the equivalents thereof.

[0122] A. Overview of the Present Invention

[0123] Conceptually, the present invention is illustrated best in FIG.1, wherein an EC 110 including a message from a sender 120 is receivedby a recipient 130. In accordance with the present invention, a device140 includes a verification component thereof that performs thefunctions of: receiving input 150 representing verification data of thesender 120; identifying a current verification status of the device 140;and communicating the identified verification status (VS) 160 to therecipient 130 in association with the EC 110. The verification datarepresented by the input 150 comprise a Secret or a biometric value.

[0124] In preferred embodiments of the present invention, discussed indetail below, the verification status 160 preferably is identifiedwithin the device by maintaining prestored data of the sender 120 and bycomparing the prestored data with the verification data that is input.Accordingly, the prestored data comprises a Secret or a biometric value,too.

[0125] In preferred embodiments, the device 140 also includes aplurality of predefined verification statuses, each representing arelational correspondence between the verification data and theprestored data. None of the verification statuses, however, actuallyreveals the verification data or the prestored data; thus, there need beno “shared secret” between the sender 120 and the recipient 130. Thedevice 140 identifies one of the predefined verification statuses asbeing the current verification status 160 based on the comparison of theverification data with the prestored data, and the device 140communicates the identified verification status 160 to the recipient 130by outputting from the device 140 an indicator of the identifiedverification status that then is transmitted to the recipient 130. Theindicator may or may not actually comprise the verification status 160;however, the indicator does indicate to the recipient 130 (or enablesthe recipient 130 to determine) the verification status 160 identifiedwithin the device.

[0126] Additionally, the device 140 preferably includes a predefinedverification status representing that no input 150 was received within apredefined period of time. The device 140 identifies this verificationstatus as being the current verification status 160 if no input 150 isreceived within such predefined period of time and, when appropriate,communicates such verification status to the recipient 130 inassociation with an EC 110. The predefined period of time may comprise,for example, the time since a resetting of the device 140 or simply apredetermined amount of time. Further, for devices 140 that “power on”only when voltage or an appropriate signal is provided to the device 140(e.g., voltage from an internal power supply, voltage from an externalpower supply, receipt of an RF signal, and the like), the predefinedamount of time may comprise the time since the device 140 was, in fact,“powered on.”

[0127] Examples of possible verification statuses include “match” and“no match” between the verification data and the prestored data, anddegrees of match or difference between the verification data andprestored data (e.g., when the verification data and prestored datacomprises biometric values). The verification statuses also may furtherrepresent whether a verification status has been provided to therecipient 130 within a predefined period of time. The predefined periodof time may comprise, for example, the time since the last comparison ofverification data with prestored data that resulted in a successfulverification, the time since the last receipt of input 150 representingverification data, or simply a predetermined amount of time, asdiscussed above.

[0128] The recipient 130 preferably has the ability of determining alevel of risk associated with the EC 110 based on the verificationstatus 160. Because of this determined level of risk associated with theEC 110, the recipient 130 is better able to evaluate the message of theEC 110. The recipient 130 preferably is represented by an electronicapparatus that includes an interface for receiving the indicatortransmitted from device 140 and logic circuitry or softwareincorporating business logic for evaluating the EC 110 from the sender120 based on the received indicator. The electronic apparatus may belocated remote to the device 140 but disposed in electroniccommunication therewith, such as over an electronic communicationsnetwork (e.g. Internet, intranet, wireless network, and the like).

[0129] It should be understood that, depending upon the context in whichthe sender 120 and recipient 130 are interacting, the message may beexplicit or implicit. If implicit, the content of the message may bepredefined. For example, the actual act of receiving an indicator of theverification status of the device 140 by the recipient 130 may, initself, represent a message agreed upon between the sender 120 and therecipient 130. In such a case, no EC 110 containing a message need besent. Furthermore, when an EC 110 actually is sent from the sender 120to the recipient 130, part or all of the EC 110 may be composed and sentfrom the device 140, rather than separate from the device 140 as shownin FIG. 1.

[0130] B. Preferred Embodiments of the Present Invention

[0131] 1. First Preferred Embodiment (Basic Model)

[0132] A first preferred embodiment 200 of the present invention isillustrated in FIG. 2a, wherein an EC 210 including a message from asender 220 is received by a recipient represented by an electronicapparatus 230, and wherein a device 240 receives input representingverification data (VD) 250 at a device interface 252. The device 240includes a verification component therein that maintains data (PD) 270of the sender 220 prestored in memory 254 of the device 240. Theverification data 250 and prestored data 270 represent Secret orbiometric values.

[0133] The verification component identifies at 256 a currentverification status of the device 240 based on a comparison of theverification data 250 with the prestored data 270. Upon receipt of asignal (S) 280, the last identified (i.e., “current”) verificationstatus of the device 240 is communicated to the recipient by outputtingfrom the device 240 an indicator 260 that then is transmitted to therecipient in association with the EC 210. The signal 280 is sent to thedevice 240, which triggers the device 240 to output the indicator 260.The signal 280 represents, for example, a request or command for theprovision of the verification status to the recipient and is generatedby the sender 220, by the electronic apparatus 230, or by anotherapparatus (not shown). The device interface 252 includes, asappropriate, one or more of the following: a user interface such as analphanumeric keypad, a touch screen display, or a biometric scanner forreceiving input directly from the sender 220; an electrical contact; astandard electronic interface with a computer bus; an antenna; or acommunications port, such as a serial port, USB port, parallel port,infrared port, or other wireless communications port.

[0134] The device 240 also includes a set of predefined verificationstatuses each representing a relational correspondence between theverification data 250 and the prestored data 270. Verification statusesof the set further represent whether an indicator 260 has been outputfrom the device 240 since the last successful verification or since thelast receipt of input representing verification data. The set alsocontains one additional predefined verification status representing thelack of input representing verification data 250 since a resetting aftera timeout or a powering on of the device 240. The indicator 260 outputfrom the device 240 is based on the last comparison of the verificationdata 250 with the prestored data 270, but only if input representingverification data 250 has been received since the resetting of thedevice 240. Otherwise, the indicator 260 indicates the lack of inputrepresenting verification data 250 since the resetting of the device240. In either case, the indicator 260 is transmitted in associationwith the EC 210, whereby the recipient is able to identify the indicator260 as relating to the EC 210. The electronic apparatus 230 includes aninterface (not shown) capable of receiving the indicator 260 from device240, and also includes logic circuitry or software incorporatingbusiness logic therein for determining the verification status based onthe indicator 260 and for evaluating the EC 210 received from the sender220 based on the verification status of the device 240.

[0135] When the verification data 250 and the prestored data 270comprise a Secret, the predefined set of verification statuses includesat least four verification statuses, comprising: a first verificationstatus representing the lack of verification data 250 since a resettingof the device; a second verification status representing a match betweenthe verification data 250 and the prestored data 270, and furtherrepresenting no other indicator 260 being output from the device 240since the match; a third verification status representing a failed matchbetween the verification data 250 and the prestored data 270; and afourth verification status representing a match between the verificationdata 250 and the prestored data 270, and further representing that anindicator 260 has been output since the match. The device 240 preferablyincludes an identification marker (“IM”) 272 stored in memory 274 andcomprising one of four binary numbers that represents the currentverification status identified by the device 240. The four binarynumbers respectively correspond to the four verification statuses andinclude: “00” identifying the first verification status; “01”identifying the second verification status; “10” identifying the thirdverification status; and “11” identifying the fourth verificationstatus. Furthermore, the indicator 260 output from the device 240preferably includes the value of the identification marker 272, with thecorrespondence of the value with the predefined verification statuses ofthe device 240 being previously known by the recipient. None of theverification statuses actually reveal the verification data 250 or theprestored data 270; thus, no “shared secret” is required between thesender 220 and the recipient. However, the recipient can infer correctknowledge of the Secret from the verification status.

[0136] Alternatively, when the verification data 250 and the prestoreddata 270 comprise biometric values, the set of predefined verificationstatuses comprises the possible percentages of match—or degrees ofdifference—between the verification data 250 and prestored data 270,together with a verification status representing the lack of inputrepresenting verification data 250 since a resetting of the device 240.For example, the predefined verification statuses comprising thepercentage match of the verification data 250 with the prestored data270 may comprise the set of percentages ranging from 0% to 100% inincrements of 1%. Preferably each one of the verification statusesrepresenting a percentage match also further represents whether anindicator 260 has been output from the device 240 since the last receiptof input representing verification data 250. The device 240 preferablyincludes the identification marker 272 for storing a value representingthe verification status identified by the device 240 as the currentverification status. Furthermore, the indicator 260 output from thedevice 240 preferably comprises the value of the identification marker272, with the correspondence of such value with the predefinedverification statuses of the device being previously known by therecipient. Again, none of the verification statuses actually revealeither of the verification data 250 or the prestored data 270; thus, nobiometric value representing the sender's irreplaceable biometriccharacteristic is communicated to the recipient. However, the recipientcan infer from the verification status the presence of the sender 220from the reading of the biometric characteristic.

[0137] A variation based on the first preferred embodiment 200 of FIG.2a is shown in FIG. 2b, and includes an I/O support element 262 fromwhich the input representing the verification data 250 is received atthe device interface 252. The I/O support element 262 includes a userinterface 258 from which input from the sender is received and an I/Ointerface 259 that communicates the input representing the verificationdata 250 to the device 240. Yet an additional variation thereof is shownin FIG. 2c, wherein the I/O support element 262 receives the indicator260 output from the device 240 and, in turn, transmits the indicator 260to the electronic apparatus 230.

[0138] As shown, the indicator 260 transmitted from the I/O supportelement 262 is the same as the indicator 260 output from the device 240.However, the indicator transmitted from the I/O support element 262 maybe different from the indicator output from the device 240, so long asthe recipient is able to determine the verification status as indicatedby the indicator 260 output from the device 240. For instance, theindicator transmitted from the I/O support element 262 may indicate notonly the verification status of the device 240, but also a verificationstatus of the I/O support element 262 when the I/O support element 262itself identifies a verification status. Furthermore, the indicator 260transmitted from the I/O support element 262 may be packaged or embeddedwithin another communication—including additional information that isdigitally signed by the I/O support element 262.

[0139] In FIGS. 2a, 2 b, and 2 c, the EC 210 is shown as beingtransmitted separate from the indicator 260. However, in the preferredembodiment of FIG. 2a and variations thereof, the indicator 260 equallymay be associated with the EC 210 by being transmitted as part of the EC210. Furthermore, the EC 210 may be output from the device 240, anassociated I/O support element 262 (not shown in FIG. 2a), or otherapparatus.

[0140] A preferred mode 300 of operation of the device of FIGS. 2a, 2 b,and 2 c is illustrated in FIG. 3 and begins with a resetting Step 304 ofthe device following a timeout or powering on of the device at 302.During the reset, the identification marker is assigned a valuecorresponding to a verification status representing the receipt of noinput representing verification data and further representing the factthat that no indicator has yet been output. The device then enters arepeating loop that begins at 306 and ends at 312 and continues withinthis loop until the device is reset, is powered off, or deactivatesafter a predetermined amount of time. The first step in the looppreferably includes the determination Step 308 whether any inputrepresenting verification data (VD) is received by the device. If thedetermination in Step 308 is positive, the current verification status(VS) of the device is identified Step 314 by comparing the verificationdata (VD) with the data prestored (PD) in memory of the device. Theverification status identified then is recorded by assigning Step 316 avalue to the identification marker stored within the memory of thedevice equal to the predefined value corresponding to the identifiedverification status.

[0141] If no input representing verification data is received in Step308 or after the value of the identification marker has been assigned inStep 316, a determination is then made of whether a signal (S) has beenor is being received by the device. If a signal is not received, thenthe loop restarts Step 306. When a signal is received, the determinationin Step 310 is positive and the indicator of the current verificationstatus of the device is output Step 318. As set forth above, theindicator comprises the value of the identification marker maintained inmemory within the device. Following the output of the indicator, thedetermination is made Step 320 whether the indicator output is the firstindicator output since receipt of input representing verification data.The loop restarts Step 306 if the determination in Step 320 is negative.If the determination in Step 320 is positive, then the verificationstatus is newly recorded by assigning Step 322 a value to theidentification marker that further represents the fact that an indicatorhas been output since input representing verification data was receivedin Step 308. The loop then restarts Step 306.

[0142] 2. Second Preferred Embodiment (Digital Signature for Indicator)

[0143] A second preferred embodiment 400 of the present invention isillustrated in FIG. 4a, wherein an EC 410 including a message from asender 420 is received by a recipient represented by an electronicapparatus 430, and wherein a device 440 receives input representingverification data (VD) 450 at a device interface 452. The device 440includes a verification component therein that maintains data (PD) 470of the sender 420 prestored in memory 454 of the device 440. Theverification data 450 and prestored data 470 represent Secret orbiometric values.

[0144] The verification component identifies at 456 a currentverification status of the device 440 based on a comparison of theverification data 450 with the prestored data 470. Upon receipt of asignal (S) 480, the last identified (i.e., “current”) verificationstatus of the device 440 is communicated to the recipient by outputtingfrom the device 440 an indicator 460 that then is transmitted to therecipient in association with the EC 410. Also upon receipt of thesignal 480, a digital signature component of the device 440 originates adigital signature (DS) 482 for the indicator 460 by calculating a hashvalue for the indicator at 490 and then encrypting the hash value at 492using a private key 495 of a public-private key pair. The digitalsignature 482 then is output from the device 440 and transmitted to therecipient with the indicator 460. For increased reliability and trust,the private key 495 is retained securely within memory 494 so that it isnever exported from the device 440 and is not discoverable from outsideof the device 440.

[0145] In this preferred embodiment, the digital signature is originatedin accordance with an elliptical curve digital signature algorithm(ECDSA) as specified in Federal Information Processing StandardsPublication 186-2, Digital Signature Standard, US DOC/NBS, Jan. 11, 1994(hereinafter “FIPS PUB 186-2”), which is incorporated herein byreference and which is available for download athttp://csrc.nist.gov/publications/fips. Accordingly, the digitalsignature 482 is generated using a random number generator, and the hashfunction at 490 is performed using the secure hash algorithm (“SHA-1”),which generates a 20-byte output regardless of the size of the inputreceived from component 456. The SHA-1 itself is specified in FederalInformation Processing Standards Publication 180-1, Secure HashStandard, US DOC/NBS, Apr. 17, 1995 (hereinafter “FIPS PUB 180-1”),which is incorporated herein by reference and which is available fordownload at http://csrc.nist.gov/publications/fips.

[0146] The signal 480 is sent to the device 440, which triggers thedevice 440 to output the indicator 460. The signal 480 represents, forexample, a request or command for the provision of the verificationstatus to the recipient and is generated by the sender 420, by theelectronic apparatus 430, or by another apparatus (not shown). Thedevice interface 452 includes, as appropriate, one or more of thefollowing: a user interface such as an alphanumeric keypad, a touchscreen display, or a biometric scanner for receiving input directly fromthe sender 420; an electrical contact; a standard electronic interfacewith a computer bus; an antenna; or a communications port, such as aserial port, USB port, parallel port, infrared port or other wirelesscommunications port.

[0147] The device 440 also includes a set of predefined verificationstatuses each representing a relational correspondence between theverification data 450 and the prestored data 470. Verification statusesof the set further represent whether an indicator 460 has been outputfrom the device since the last successful verification or since the lastreceipt of input representing verification data. The set also containsone additional predefined verification status representing the lack ofinput representing verification data 450 since a resetting after atimeout or a powering on of the device 440. The indicator 460 outputfrom the device 440 is based on the last comparison of the verificationdata 450 with the prestored data 470, but only if input representingverification data 450 has been received since the resetting of thedevice 440. Otherwise, the indicator 460 indicates the lack of inputrepresenting verification data 450 since the resetting of the device440. In either case, the indicator 460 is transmitted with the digitalsignature 482 therefor in association with the EC 410, whereby therecipient is able to identify the indicator 460 as relating to the EC410.

[0148] The electronic apparatus 430 includes an interface (not shown)capable of receiving the indicator 460 and digital signature 482 fromdevice 440. The electronic apparatus 430 also includes logic circuitryor software incorporating business logic therein for determining theverification status of the device based on the indicator 460 and forevaluating the EC 410 received from the sender 420 based on theverification status of the device 440. The electronic apparatus 430 alsodecrypts the digital signature 482 to confirm the authenticity of theindicator 460 (i.e., the electronic apparatus 430 conducts MessageAuthentication with respect to the indicator 460). The decryption isperformed using the public key, which corresponds to the private key 495and which may be received in association with the digital signature 482or otherwise known or obtained beforehand by the recipient.

[0149] When the verification data 450 and the prestored data 470comprise a Secret, the predefined set of verification statuses includesat least four verification statuses, comprising: a first verificationstatus representing the lack of verification data 450 since a resettingof the device; a second verification status representing a match betweenthe verification data 450 and the prestored data 470, and furtherrepresenting no other indicator 460 being output from the device 440since the match; a third verification status representing a failed matchbetween the verification data 450 and the prestored data 470; and afourth verification status representing a match between the verificationdata 450 and the prestored data 470, and further representing that anindicator 460 has been output since the match. The device 440 preferablyincludes an identification marker (“IM”) 472 stored in memory 474 andcomprising one of four binary numbers that represents the currentverification status identified by the device 440. The four binarynumbers respectively correspond to the four verification statuses andinclude: “00” identifying the first verification status; “01”identifying the second verification status; “10” identifying the thirdverification status; and “11” identifying the fourth verificationstatus. Furthermore, the indicator 460 output from the device 440preferably includes the value of the identification marker 472, with thecorrespondence of the value with the predefined verification statuses ofthe device 440 being previously known by the recipient. None of theverification statuses actually reveal the verification data 450 or theprestored data 470; thus, no “shared secret” is required between thesender 420 and the recipient. However, the recipient can infer correctknowledge of the Secret from the verification status.

[0150] Alternatively, when the verification data 450 and the prestoreddata 470 comprise biometric values, the set of predefined verificationstatuses comprises the possible percentages of match—or degrees ofdifference—between the verification data 450 and prestored data 470,together with a verification status representing the lack of inputrepresenting verification data 450 since a resetting of the device 440.For example, the predefined verification statuses comprising thepercentage match of the verification data 450 with the prestored data470 may comprise the set of percentages ranging from 0% to 100% inincrements of 1%. Each one of the verification statuses representing apercentage match also further represents whether an indicator 460 hasbeen output from the device 440 since the last receipt of inputrepresenting verification data 450. The device 440 preferably includesthe identification marker 472 for storing a value representing theverification status identified by the device 440 as the currentverification status. Furthermore, the indicator 460 output from thedevice 440 preferably comprises the value of the identification marker472, and the correspondence of such value with the predefinedverification statuses of the device is previously known by therecipient. Again, none of the verification statuses actually revealeither of the verification data 450 or the prestored data 470; thus, nobiometric value representing the sender's irreplaceable biometriccharacteristic is communicated to the recipient. However, the recipientcan infer from the verification status the presence of the sender 420from the reading of the biometric characteristic.

[0151] A variation based on the second preferred embodiment 400 of FIG.4a is shown in FIG. 4b, and includes an I/O support element 462 fromwhich the input representing the verification data 450 is received atthe device interface 452. The I/O support element 462 includes a userinterface 458 from which input from the sender 420 is received and anI/O interface 459 that communicates the input representing theverification data 450 to the device 440. Yet an additional variationthereof is shown in FIG. 4c, wherein the I/O support element 462receives the indicator 460 and digital signature 482 therefor outputfrom the device 440. The I/O support element 462, in turn, transmits theindicator 460 and digital signature 482 to the external electronicapparatus 430.

[0152] As shown, the indicator 460 transmitted from the I/O supportelement 462 is the same as the indicator 460 output from the device 440.However, the indicator transmitted from the I/O support element 462 maybe different from the indicator output from the device 440, so long asthe recipient is able to determine both the verification status asindicated by the indicator 460 output from the device 440, and the bitpattern of the indicator 460 for which the digital signature wasoriginated by the device 440. For instance, the indicator transmittedfrom the I/O support element 462 may indicate not only the verificationstatus of the device 440, but also a verification status of the I/Osupport element 462 when the I/O support element 462 itself identifies averification status. Furthermore, the indicator 460 transmitted from theI/O support element 462 may be packaged or embedded within anothercommunication—including additional information that is digitally signedby the I/O support element 462.

[0153] Furthermore, in FIGS. 4a, 4 b, and 4 c, the EC 410 is shown asbeing transmitted separate from the indicator 460 and digital signature482. However, in the preferred embodiment of FIG. 4a and any variationsthereof, the indicator 460 and digital signature 482 equally may beassociated with the EC 410 by being transmitted as part of the EC 410.Furthermore, the EC 410 may be output from the device 440, an associatedI/O support element 462 (not shown in FIG. 4a), or other apparatus.

[0154] A preferred mode 500 of operation of the device of FIGS. 4a, 4 b,and 4 c is illustrated in FIG. 5 and begins with a resetting Step 504 ofthe device following a timeout or powering on of the device at 502.During the reset, the identification marker is assigned a valuecorresponding to a verification status representing the receipt of noinput representing verification data and further representing the factthat that no indicator has yet been output. The device then enters arepeating loop that begins at 506 and ends at 512 and continues withinthis loop until the device is reset, is powered off, or deactivatesafter a predetermined amount of time. The first step in the looppreferably includes the determination Step 508 whether any inputrepresenting verification data (VD) is received by the device. If thedetermination in Step 508 is positive, the current verification status(VS) of the device is identified Step 514 by comparing the verificationdata (VD) with the data prestored (PD) in memory of the device. Theverification status identified then is recorded by assigning Step 516 avalue to the identification marker stored within the memory of thedevice equal to the predefined value corresponding to the identifiedverification status.

[0155] If no input representing verification data is received in Step508 or after the value of the identification marker has been assigned inStep 516, a determination is then made of whether a signal (S) has beenor is being received by the device. If a signal is not received, thenthe loop restarts Step 506. When a signal is received, the determinationin Step 510 is positive and a digital signature is originated Step 518for the indicator of the current verification status. The indicator andthe digital signature therefor then are output Step 520. As set forthabove, the indicator comprises the value of the identification markermaintained in memory within the device. Following the output of theindicator and digital signature, the determination is made Step 522whether the indicator output is the first indicator output since receiptof input representing verification data. The loop restarts Step 506 ifthe determination in Step 522 is negative. If the determination in Step522 is positive, then the verification status is newly recorded byassigning Step 524 a value to the identification marker that furtherrepresents the fact that an indicator has been output since inputrepresenting verification data was received in Step 508. The loop thenrestarts Step 506.

[0156] 3. Third Preferred Embodiment (Digital Signature for Message)

[0157] A third preferred embodiment 600 of the present invention isillustrated in FIG. 6a, wherein an EC 610 including a message from asender 620 is received by a recipient represented by an electronicapparatus 630, and wherein a device 640 receives input representingverification data (VD) 650 at a device interface 652. The device 640includes a verification component therein that maintains data (PD) 670of the sender 620 prestored in memory 654 of the device 640. Theverification data 650 and prestored data 670 represent Secret orbiometric values.

[0158] The verification component identifies at 656 a currentverification status of the device 640 based on a comparison of theverification data 650 with the prestored data 670. Upon receipt of asignal (S) 680, the last identified (i.e., “current”) verificationstatus of the device 640 is communicated to the recipient by outputtingfrom the device 640 an indicator 660 that then is transmitted to therecipient in association with the EC 610. The signal 680 is sent to thedevice 640, which triggers the device 640 to output the indicator 660.The signal 680 represents, for example, a request or command for theprovision of the verification status to the recipient and is generatedby the sender 620, by the electronic apparatus 630, or by anotherapparatus (not shown). The device interface 652 includes, asappropriate, one or more of the following: a user interface such as analphanumeric keypad, a touch screen display, or a biometric scanner forreceiving input directly from the sender 620; an electrical contact; astandard electronic interface with a computer bus; an antenna; or acommunications port, such as a serial port, USB port, parallel port,infrared port or other wireless communications port.

[0159] The device 640 receives at the device interface 652 data (MD) 622representing the message of the EC 610. The message data may comprisethe message itself, a message digest thereof, or the result of someother processing of the message (M). The device 640 includes a digitalsignature component that, upon receipt of the message data 622,originates a digital signature (DS) 686 for the message data 622. Thedigital signature 686 is originated by calculating a hash value for themessage data 622 at 690 and then encrypting the hash value at 692 usinga private key 695 of a public-private key pair. For increasedreliability and trust, the private key 695 is retained securely withinmemory 694 so that it is never exported from the device 640 and is notdiscoverable from outside of the device 640. The digital signature isoriginated in accordance with the ECDSA as specified in FIPS PUB 186-2.Accordingly, the digital signature 682 is generated using a randomnumber generator, and the hash function at 690 is performed using SHA-1,which generates a 20-byte output regardless of the size of the inputreceived. The digital signature 686 then is output from the device 640and transmitted to the recipient with the indicator 660.

[0160] In alternative preferred embodiments, if the message data 622 hasalready been hashed before it is received by the device 640, then thehash function is omitted. In such alternative embodiments, the device640 is configured not to hash any message data 622 or not to hashmessage data 622 if a specific instruction, signal, or command isreceived.

[0161] The device 640 also includes a set of predefined verificationstatuses each representing a relational correspondence between theverification data 650 and the prestored data 670. Verification statusesof the set further represent whether an indicator 660 has been outputfrom the device 640 since the last successful verification or since thelast receipt of input representing verification data. The set alsocontains one additional predefined verification status representing thelack of input representing verification data 650 since a resetting aftera timeout or a powering on of the device 640. The indicator 660 outputfrom the device 640 is based on the last comparison of the verificationdata 650 with the prestored data 670, but only if input representingverification data 650 has been received since the resetting of thedevice 640. Otherwise, the indicator 660 indicates the lack of inputrepresenting verification data 650 since the resetting of the device640.

[0162] In either case, the indicator 660 is transmitted with the digitalsignature 686 in association with the EC 610, whereby the recipient isable to identify the indicator 660 and digital signature 686 as relatingto the EC 610. The electronic apparatus 630 includes an interface (notshown) capable of receiving the indicator 660 and digital signature 686from the device 640. The electronic apparatus 630 also includes logiccircuitry or software incorporating business logic therein fordetermining the verification status of the device based on theindicator, and for evaluating the EC 610 received from the sender 620based on the determined verification status. The electronic apparatus630 also decrypts the digital signature 686 to confirm the authenticityof the message of the EC 610. The decryption is performed with thepublic key, which corresponds with the private key 695 and which may bereceived in association with the digital signature 686 or known orobtained beforehand by the recipient. Of course, in calculating a hashvalue for comparison, the electronic apparatus 630 performs anynecessary processing to the message in order to produce the message datafor which the digital signature was originated.

[0163] When the verification data 650 and the prestored data 670comprise a Secret, the predefined set of verification statuses includesat least four verification statuses, comprising: a first verificationstatus representing the lack of verification data 650 since a resettingof the device; a second verification status representing a match betweenthe verification data 650 and the prestored data 670, and furtherrepresenting no other indicator 660 being output from the device 640since the match; a third verification status representing a failed matchbetween the verification data 650 and the prestored data 670; and afourth verification status representing a match between the verificationdata 650 and the prestored data 670, and further representing that anindicator 660 has been output since the match. The device 640 preferablyincludes an identification marker (“IM”) 672 stored in memory 674 andcomprising one of four binary numbers that represents the currentverification status identified by the device 640. The four binarynumbers respectively correspond to the four verification statuses andinclude: “00” identifying the first verification status; “01”identifying the second verification status; “10” identifying the thirdverification status; and “11” identifying the fourth verificationstatus. Furthermore, the indicator 660 output from the device 640preferably includes the value of the identification marker 672, with thecorrespondence of the value with the predefined verification statuses ofthe device being previously known by the recipient. None of theverification statuses actually reveal the verification data 650 or theprestored data 670; thus, no “shared secret” is required between thesender 620 and the recipient. However, the recipient can infer correctknowledge of the Secret from the verification status.

[0164] Alternatively, when the verification data 650 and the prestoreddata 670 comprise biometric values, the set of predefined verificationstatuses comprises the possible percentages of match—or degrees ofdifference—between the verification data 650 and prestored data 670,together with a verification status representing the lack of inputrepresenting verification data 650 since a resetting of the device 640.For example, the predefined verification statuses comprising thepercentage match of the verification data 650 with the prestored data670 may comprise the set of percentages ranging from 0% to 100% inincrements of 1%. Preferably each one of the verification statusesrepresenting a percentage match also further represents whether anindicator 660 has been output from the device 640 since the last receiptof input representing verification data 650. The device 640 preferablyincludes the identification marker 672 for storing a value representingthe verification status identified by the device 640 as the currentverification status. Furthermore, the indicator 660 output from thedevice 640 preferably comprises the value of the identification marker672, with the correspondence of such value with the predefinedverification statuses of the device being previously known by therecipient. Again, none of the verification statuses actually revealeither of the verification data 650 or the prestored data 670; thus, nobiometric value representing the sender's irreplaceable biometriccharacteristic is communicated to the recipient. However, the recipientcan infer from the verification status the presence of the sender fromthe reading of the biometric characteristic.

[0165] A variation based on the third preferred embodiment 600 of FIG.6a is shown in FIG. 6b, and includes an I/O support element 662 fromwhich input representing the verification data 650 and inputrepresenting the message data 622 are received by the device 640. TheI/O support element 662 includes a user interface 658 from which inputfrom the sender 620 is received and an I/O interface 659 thatcommunicates the input representing the verification data 650 and inputrepresenting the message data 622 to the device 640. Although themessage data 622 is shown coming from the I/O support element 662, it ispossible for some or all of the message data 622 to be composed withinthe device 640 or another apparatus (not shown). Yet an additionalvariation thereof is shown in FIG. 6c, wherein the I/O support element662 receives the indicator 660 and digital signature 686 output from thedevice 640. The I/O support element 662, in turn, transmits theindicator 660 and the digital signature 686 to the electronic apparatus630.

[0166] As shown, the indicator 660 and digital signature 686 transmittedfrom the I/O support element 662 are the same as the indicator 660 anddigital signature 686 output from the device 640. However, the indicatortransmitted from the I/O support element 662 may be different from theindicator output from the device 640, so long as the recipient is ableto determine the verification status as indicated by the indicator 660output from the device 640. For instance, the indicator transmitted fromthe I/O support element 662 may indicate not only the verificationstatus of the device 640, but also a verification status of the I/Osupport element 662 when the I/O support element 662 itself identifies averification status. Furthermore, the indicator 660 and digitalsignature 686 transmitted from the I/O support element 662 may bepackaged or embedded within another communication—including additionalinformation that is digitally signed by the I/O support element 662.

[0167] Furthermore, in FIGS. 6a, 6 b, and 6 c, the EC 610 is shown asbeing transmitted separate from the indicator 660 and digital signature686. However, in the preferred embodiment of FIG. 6a and any variationsthereof, the indicator 660 and digital signature 686 equally may beassociated with the EC 610 by being transmitted as part of the EC 610.Furthermore, the EC 610 may be output from the device 640, an associatedI/O support element 662 (not shown in FIG. 6a), or other apparatus.

[0168] A preferred mode 700 of operation of the device of FIGS. 6a, 6 b,and 6 c is illustrated in FIG. 7 and begins with a resetting Step 704 ofthe device following a timeout or powering on of the device at 702.During the reset, the identification marker is assigned a valuecorresponding to a verification status representing the receipt of noinput representing verification data and further representing the factthat that no indicator has yet been output. The device then enters arepeating loop that begins at 706 and ends at 714 and continues withinthis loop until the device is reset, is powered off, or deactivatesafter a predetermined amount of time. The first step in the looppreferably includes the determination Step 708 whether any inputrepresenting verification data (VD) is received by the device. If thedetermination in Step 708 is positive, the current verification status(VS) of the device is identified Step 716 by comparing the verificationdata (VD) with the data prestored (PD) in memory of the device. Theverification status identified then is recorded by assigning Step 718 avalue to the identification marker stored within the memory of thedevice equal to the predefined value corresponding to the identifiedverification status.

[0169] If no input representing verification data is received in Step708 or after the value of the identification marker is recorded in Step718, the next step in the loop preferably includes the determinationStep 710 whether any input representing message data (MD) is received bythe device. If the determination in Step 710 is positive, the deviceoriginates Step 720 a digital signature for the message data. Thedigital signature for the message data is then output Step 722 from thedevice.

[0170] If no input representing message data is received in Step 710 orafter the digital signature for the message data is output in Step 722,a determination is then made of whether a signal (S) has been or isbeing received by the device. If a signal is not received, then the looprestarts Step 706. When a signal is received, the determination in Step712 is positive and the indicator of the current verification status ofthe device is output Step 724. As set forth above, the indicatorcomprises the value of the identification marker maintained in memorywithin the device. Following the output of the indicator, thedetermination is made Step 726 whether the indicator output is the firstindicator output since receipt of input representing verification data.The loop restarts Step 706 if the determination in Step 726 is negative.If the determination in Step 726 is positive, then the verificationstatus is newly recorded by assigning Step 728 a value to theidentification marker that further represents the fact that an indicatorhas been output since input representing verification data was receivedin Step 708. The loop then restarts Step 706.

[0171] 4. Fourth Preferred Embodiment (Digital Signature for PrestoredMessage)

[0172] A fourth preferred embodiment 800 of the present invention isillustrated in FIG. 8a, wherein a device 840 includes message data (MD)822 representing a predefined message that is maintained in memory, ofthe device 840. Furthermore, it is preferred that the content of thepredefined message be known in advance by the recipient, whereby themessage is implicitly received by the recipient in the act of receivinga digital signature 886 for the message data 822. However, in the eventthat the recipient does not have knowledge of the predefined message,the device 840 preferably includes the option of exporting the messagedata 822 for communication to the recipient as shown by the dotted linein FIG. 8a.

[0173] The device 840 includes a digital signature component that, uponreceipt of a signal (S₁) 898 at the device interface 852, originates thedigital signature 886 for the message data 822 by calculating a hashvalue therefor at 890 and then encrypting the hash value at 892 using aprivate key 895 of a public-private key pair, and then outputs thedigital signature 886 for transmitting to the recipient. For increasedreliability and trust, the private key 895 is retained securely withinmemory 894 so that it is never exported from the device 840 and is notdiscoverable from outside of the device 840. The digital signature isoriginated in accordance with the ECDSA as specified in FIPS PUB 186-2.Accordingly, the digital signature 882 is generated using a randomnumber generator, and the hash function at 890 is performed using SHA-1,which generates a 20-byte output regardless of the size of the inputreceived.

[0174] The signal 898 represents, for example, a request or commandgenerated by the sender 820 for the communication of the digitalsignature 886 to the recipient or, alternatively, the signal 898 maysimply comprise the receipt from the sender 820 of input representingverification data 850 by the device 840. In this regard, the device 840receives input representing verification data (VD) 850 at a deviceinterface 852. The device 840 includes a verification component thereinthat maintains data (PD) 870 of the sender 820 prestored in memory 854of the device 840. The verification data 850 and prestored data 870represent Secret or biometric values. The verification component of thedevice 840 identifies at 856 a current verification status of the device840 based on a comparison of the verification data 850 with theprestored data 870.

[0175] Upon receipt of a signal (S₂) 880, the last identified (i.e.,“current”) verification status of the device 840 is communicated to therecipient by outputting from the device 840 an indicator (IVS) 860 thatthen is transmitted to the recipient in association with the digitalsignature 886. The signal 880 is sent to the device 840, which triggersthe device 840 to output the indicator 860. The signal 880 represents,for example, a request or command for the provision of the verificationstatus to the recipient and is generated by the sender 820, by theelectronic apparatus 830, or by another apparatus (not shown).Alternatively, the signal 880 may comprise the receipt of the inputrepresenting the verification data 850 itself; thus, it is possible forsignal (S₁) 898 and signal (S₂) 880 to be the same signal.

[0176] The device interface 852 includes, as appropriate, one or more ofthe following: a user interface such as an alphanumeric keypad, a touchscreen display, or a biometric scanner for receiving input directly fromthe sender 820; an electrical contact; a standard electronic interfacewith a computer bus; an antenna; or a communications port, such as aserial port, USB port, parallel port, infrared port or other wirelesscommunications port.

[0177] The device 840 includes a set of predefined verification statuseseach representing a relational correspondence between the verificationdata 850 and the prestored data 870. Verification statuses of the setfurther represent whether an indicator 860 has been output from thedevice 840 since the last successful verification or since the lastreceipt of input representing verification data 850. The set alsocontains one additional predefined verification status representing thelack of input representing verification data 850 since a resetting aftera timeout or a powering on of the device 840. The indicator 860 outputfrom the device 840 is based on the last comparison of the verificationdata 850 with the prestored data 870, but only if input representingverification data 850 has been received since the resetting of thedevice 840. Otherwise, the indicator 860 indicates the lack of inputrepresenting verification data 850 since the resetting of the device840.

[0178] In either case, the indicator 860 is transmitted with the digitalsignature 886, whereby the recipient is able to identify the indicator860 as relating to the digital signature 686. The electronic apparatus830 includes an interface (not shown) capable of receiving the indicator860 and digital signature 886. The electronic apparatus 830 alsoincludes logic circuitry or software incorporating business logictherein for determining the verification status of the device 840 basedon the indicator 860, and for evaluating the implicit (or explicit)message received from the sender 820 based on the determinedverification status. The electronic apparatus 830 also decrypts thedigital signature 886 to confirm the authenticity of the message. Thedecryption is performed with the public key, which corresponds with theprivate key 895 and which may be received in association with thedigital signature 886 or known or obtained beforehand by the recipient.

[0179] When the verification data 850 and the prestored data 870comprise a Secret, the predefined set of verification statuses includesat least four verification statuses, comprising: a first verificationstatus representing the lack of verification data 850 since a resettingof the device; a second verification status representing a match betweenthe verification data 850 and the prestored data 870, and furtherrepresenting no other indicator 860 being output from the device 840since the match; a third verification status representing a failed matchbetween the verification data 850 and the prestored data 870; and afourth verification status representing a match between the verificationdata 850 and the prestored data 870, and further representing the outputof an indicator 860 since the match. The device 840 preferably includesan identification marker (“IM”) 872 stored in memory 874 and comprisingone of four binary numbers that represents the current verificationstatus identified by the device 840. The four binary numbersrespectively correspond to the four verification statuses and include:“00” identifying the first verification status; “01” identifying thesecond verification status; “10” identifying the third verificationstatus; and “11” identifying the fourth verification status.Furthermore, the indicator 860 output from the device 840 preferablyincludes the value of the identification marker 872, with thecorrespondence of the value with the predefined verification statuses ofthe device being previously known by the recipient. None of theverification statuses actually reveal the verification data 850 or theprestored data 870; thus there is no “shared secret” between the sender820 and the recipient. However, the recipient can infer correctknowledge of the Secret from the verification status.

[0180] Alternatively, when the verification data 850 and the prestoreddata 870 comprise biometric values, the set of predefined verificationstatuses comprises the possible percentages of match—or degrees ofdifference—between the verification data 850 and prestored data 870,together with a verification status representing the lack of inputrepresenting verification data 850 since a resetting of the device 840.For example, the predefined verification statuses comprising thepercentage match of the verification data 850 with the prestored data870 may comprise the set of percentages ranging from 0% to 100% inincrements of 1%. Preferably each one of the verification statusesrepresenting a percentage match also further represents whether anindicator 860 has been output from the device 840 since the last receiptof input representing verification data 850. The device 840 preferablyincludes the identification marker 872 for storing a value representingthe verification status identified by the device 840 as the currentverification status. Furthermore, the indicator 860 output from thedevice 840 preferably comprises the value of the identification marker872, and the correspondence of such value with the predefinedverification statuses of the device is previously known by therecipient. Again, none of the verification statuses actually revealeither of the verification data 850 or the prestored data 870; thus, nobiometric value representing the sender's irreplaceable biometriccharacteristic is communicated to the recipient. However, the recipientcan infer from the verification status the presence of the sender fromthe reading of the biometric characteristic.

[0181] A variation based on the fourth preferred embodiment 800 of FIG.8a is shown in FIG. 8b, and includes an I/O support element 862 fromwhich input representing the verification data 850 is received by thedevice 840. The I/O support element 862 includes a user interface 858from which input from the sender 820 is received and an I/O interface859 that communicates the input representing the verification data 850to the device 840. Yet an additional variation thereof is shown in FIG.8c, wherein the I/O support element 862 receives the indicator 860 anddigital signature 886 (and optionally the message data 822) output fromthe device 840. The I/O support element 862, in turn, transmits theindicator 860 and the digital signature 886 (and optionally the messagedata 822) to the electronic apparatus 830.

[0182] As shown, the indicator 860 and digital signature 886 transmittedfrom the I/O support element 862 are the same as the indicator 860 anddigital signature 886 output from the device 840. However, the indicatortransmitted from the I/O support element 862 may be different from theindicator output from the device 840, so long as the recipient is ableto determine the verification status as indicated by the indicator 860output from the device 840. For instance, the indicator transmitted fromthe I/O support element 862 may indicate not only the verificationstatus of the device 840, but also a verification status of the I/Osupport element 862 when the I/O support element 862 itself identifies averification status. Furthermore, the indicator 860 and digitalsignature 886 transmitted from the I/O support element 862 may bepackaged or embedded within another communication—including additionalinformation that is digitally signed by the I/O support element 862.

[0183] A further variation based on the fourth preferred embodiment 800of FIG. 8a is shown in FIG. 8d, in which the message data 822 stored inthe device 840 is a calculated hash value of the predefined message. Inthis case, the device 840 generates a digital signature 886 for thepredefined message by directly encrypting the message data 822 at 892,and the component 890 for calculating the hash value in FIG. 8a isomitted from the device of FIG. 8d. In this example, it is assumed thatthe recipient knows the predefined message corresponding to the messagedata 822 stored within the device 840; thus, there is no need tocommunicate the message (or message data 822) from the device 840 to therecipient.

[0184] A preferred mode 900 of operation of the device of FIGS. 8a, 8 b,8 c, and 8 d is illustrated in FIG. 9 and begins with a resetting Step904 of the device following a timeout or powering on of the device at902. During the reset, the identification marker is assigned a valuecorresponding to a verification status representing the receipt of noinput representing verification data and further representing the factthat that no indicator has yet been output. The device then enters arepeating loop that begins at 906 and ends at 914 and continues withinthis loop until the device is reset, is powered off, or deactivatesafter a predetermined amount of time. The first step in the looppreferably includes the determination Step 908 whether any inputrepresenting verification data (VD) is received by the device. If thedetermination in Step 908 is positive, the current verification status(VS) of the device is identified Step 916 by comparing the verificationdata (VD) with the data prestored (PD) in memory of the device. Theverification status identified then is recorded by assigning Step 918 avalue to the identification marker stored within the memory of thedevice equal to the predefined value corresponding to the identifiedverification status.

[0185] If no input representing verification data is received in Step908 or after the value of the identification marker is recorded in Step918, the next step in the loop preferably includes the determinationStep 910 whether any signal S₁ is received by the device. If thedetermination in Step 910 is positive, the device originates Step 920(or generates, as applicable) a digital signature for the predefinedmessage data. The digital signature for the predefined message data isthen output Step 922 from the device.

[0186] If signal S₁ is not received in Step 910 or after the digitalsignature for the predefined message data is output in Step 922, adetermination is then made of whether a signal S₂ has been or is beingreceived by the device. If a signal S₂ is not received, then the looprestarts Step 906. When a signal S₂ is received, the determination inStep 912 is positive and the indicator of the current verificationstatus of the device is output Step 924. As set forth above, theindicator comprises the value of the identification marker maintained inmemory within the device. Following the output of the indicator, thedetermination is made Step 926 whether the indicator output is the firstindicator output since receipt of input representing verification data.The loop restarts Step 906 if the determination in Step 926 is negative.If the determination in Step 926 is positive, then the verificationstatus is newly recorded by assigning Step 928 a value to theidentification marker that further represents the fact that an indicatorhas been output since input representing verification data was receivedin Step 908. The loop then restarts Step 906.

[0187] 5. Fifth Preferred Embodiment (Secret and Biometric VerificationData)

[0188] A fifth preferred embodiment 1000 of the present invention isillustrated in FIG. 10a, wherein an EC 1010 including a message from asender 1020 is received by a recipient represented by an electronicapparatus 1030, and wherein a device 1040 receives input representingverification data for a Secret (SVD) 1051 and input representingverification data for a biometric characteristic (BVD) 1053 at a deviceinterface 1052. The device 1040 includes a verification componenttherein that maintains data of the sender 1020 prestored in memory ofthe device 1040. The prestored data (SPD) 1042 is located in memory 1041and comprises a value for a Secret, and the prestored data (BPD) 1044 islocated in memory 1043 and comprises a value for a biometriccharacteristic.

[0189] The verification component identifies at 1056 a currentverification status of the device 1040 based on respective comparisonsof the verification data 1051,1053 with the prestored data 1042,1044.Upon receipt of a signal (S) 1080, the last identified (i.e., “current”)verification status of the device 1040 is communicated to the recipientby outputting from the device 1040 an indicator 1060 that is transmittedto the recipient in association with the EC 1010. The signal 1080 issent to the device 1040, which triggers the device 1040 to output theindicator 1060. The signal 1080 represents, for example, a request orcommand for the provision of the verification status to the recipientand is generated by the sender 1020, by the electronic apparatus 1030,or by another apparatus (not shown). The device interface 1052 includes,as appropriate, one or more of the following: a user interface such asan alphanumeric keypad, a touch screen display, or a biometric scannerfor receiving input directly from the sender 1020; an electricalcontact; a standard electronic interface with a computer bus; anantenna; or a communications port, such as a serial port, USB port,parallel port, infrared port or other wireless communications port.

[0190] The device 1040 also receives at the device interface 1052 data(MD) 1022 representing the message of the EC 1010. The message data 1022may comprise the message (M) itself, a message digest thereof, or theresult of some other processing of the message. The device 1040 includesa digital signature component that, upon receipt of the message data1022, originates a digital signature (DS) 1086 for the message data 1022by calculating a hash value therefor at 1090 and then encrypting thehash value at 1092 using a private key 1095 of a public-private keypair. For increased reliability and trust, the private key 1095 isretained securely within memory 1094 so that it is never exported fromthe device 1040 and is not discoverable from outside of the device 1040.The digital signature 1086 then is output from the device 1040 andtransmitted to the recipient with the indicator 1060. The digitalsignature is originated in accordance with the ECDSA as specified inFIPS PUB 186-2. Accordingly, the digital signature 1082 is generatedusing a random number generator, and the hash function at 1090 isperformed using SHA-1, which generates a 20-byte output regardless ofthe size of the input received.

[0191] In alternative preferred embodiments, if the message data 1022has already been hashed before it is received by the device 1040, thenthe hash function is omitted. In such alternative embodiments, thedevice 1040 is configured not to hash any message data 1022 or not tohash message data 1022 if a specific instruction, signal, or command isreceived.

[0192] The device 1040 also includes a set of predefined verificationstatuses each representing a relational correspondence between theverification data 1051,1053 and the prestored data 1042,1043.Verification statuses of the set further represent whether an indicator1060 has been output from the device 1040 since the last successfulverification or since the last receipt of input representingverification data. The set also contains one additional predefinedverification status representing the lack of input representingverification data 1051 since a resetting after a timeout or a poweringon of the device 1040, and one predefined verification statusrepresenting the lack of input representing verification data 1053 sincea resetting after a timeout or a powering on of the device 1040. Theindicator 1060 output from the device 1040 is based on the lastcomparison of each of verification data 1051 (if received) withprestored data 1042 and of verification data 1053 (if received) withprestored data 1044. Otherwise, the indicator 1060 indicates the lack ofinput representing verification data 1051,1053 since the resetting ofthe device 1040.

[0193] In either case, the indicator 1060 is transmitted with thedigital signature 1086 in association with the EC 1010, whereby therecipient is able to identify the indicator 1060 and digital signature1086 as relating to the EC 1010. The electronic apparatus 1030 includesan interface (not shown) capable of receiving the indicator 1060 anddigital signature 1086. The electronic apparatus 1030 also includeslogic circuitry or software incorporating business logic therein fordetermining the verification status of the device 1040 based on theindicator 1060, and for evaluating the EC 1010 received from the sender1020 based on the determined verification status. The electronicapparatus 1030 also decrypts the digital signature 1086 to confirm theauthenticity of the message of the EC 1010. The decryption is performedwith the public key, which corresponds with the private key 1095 andwhich may be received in association with the digital signature 1086 orknown or obtained beforehand by the recipient. In calculating a hashvalue for comparison, the electronic apparatus 1030 also performs anynecessary processing to the message in order to produce the messagedigest for which the digital signature was originated.

[0194] Verification data 1051 and prestored data 1042 represent aSecret, and a comparison of verification data 1051 received with theprestored data 1042 produces a result preferably out of four possibleoutcomes, including: a first outcome representing the lack ofverification data 1050 since a resetting of the device 1040; a secondoutcome representing a match between the verification data 1051 and theprestored data 1042, and further representing no other indicator 1060being output from the device 1040 since the match; a third outcomerepresenting a failed match between the verification data 1051 and theprestored data 1042; and a fourth outcome representing a match betweenthe verification data 1051 and the prestored data 1042, and furtherrepresenting the output of an indicator 1060 since the match.

[0195] Verification data 1053 and prestored data 1044 represent abiometric characteristic, and a comparison of verification data 1053received with the prestored data 1044 produces a result preferably outof a predefined number of possible outcomes. Each outcome represents apossible percentage of match—or degree of difference—between theverification data 1053 and prestored data 1044 that is allowed, togetherwith a verification status representing the lack of input forverification data 1053 since a resetting of the device 1040. Forexample, the predefined outcomes comprising the percentage match of theverification data 1053 with the prestored data 1044 may comprise the setof percentages ranging from 0% to 100% in increments of 1%. Preferablyeach one of the outcomes representing a percentage match also furtherrepresents whether an indicator 1060 has been output from the device1040 since the last receipt of input representing verification data1053.

[0196] The device 1040 preferably includes an identification marker(“IM”) 1072 stored in memory 1074 and comprising one of the set ofpredefined verification statuses of the device. The set of predefinedverification statuses preferably comprises all of the possiblecombinations of outcomes from the comparison of the verification data1051 with the prestored data 1042 in addition to all of the possibleoutcomes from the comparison of the verification data 1053 with theprestored data 1044. Furthermore, the indicator 1060 output from thedevice 1040 preferably includes the value of the identification marker1072, with the correspondence of the value of the identification markerwith the predefined verification statuses of the device 1040 beingpreviously known by the recipient. None of the verification statusesactually reveal any of the verification data 1051,1053 or the prestoreddata 1042,1044; thus, no “shared secret” is required between the sender1020 and the recipient, and no biometric value representing the sender'sirreplaceable biometric characteristic is communicated to the recipient.However, the recipient can infer correct knowledge of the Secret andcorrect input of a biometric value from the verification status.

[0197] A variation based on the fifth preferred embodiment 1000 of FIG.10a is shown in FIG. 10b, and includes an I/O support element 1062 fromwhich input representing the verification data 1051,1053 and inputrepresenting the message data 1022 is received by the device 1040. TheI/O support element 1062 includes a user interface 1058 from which inputfrom the sender 1020 is received and an I/O interface 1059 thatcommunicates the input representing the verification data 1051,1053 tothe device 1040. Although the message data 1022 is shown coming from theI/O support element 1062, it is possible for some or all of the messagedata 1022 to originate with the device 1040 or another apparatus (notshown). Yet an additional variation thereof is shown in FIG. 10c,wherein the I/O support element 1062 receives the indicator 1060 anddigital signature 1086 output from the device 1040. The 110 supportelement 1062, in turn, transmits the indicator 1060 and the digitalsignature 1086 to the electronic apparatus 1030.

[0198] As shown, the indicator 1060 and digital signature 1086transmitted from the 110 support element 1062 are the same as theindicator 1060 and digital signature 1086 output from the device 1040.However, the indicator transmitted from the I/O support element 1062 maybe different from the indicator output from the device 1040, so long asthe recipient is able to determine the verification status as indicatedby the indicator 1060 output from the device 1040. For instance, theindicator transmitted from the I/O support element 1062 may indicate notonly the verification status of the device 1040, but also a verificationstatus of the 1(O support element 1062 when the I/O support element 1062itself identifies a verification status. Furthermore, the indicator 1060and digital signature 1086 transmitted from the I/O support element 1062may be packaged or embedded within another communication—includingadditional information that is digitally signed by the I/O supportelement 1062.

[0199] Furthermore, in FIGS. 10a, 10 b, and 10 c, the EC 1010 is shownas being transmitted separate from the indicator 1060 and digitalsignature 1086. However, in the preferred embodiment of FIG. 10a and anyvariations thereof, the indicator 1060 and digital signature 1086equally may be associated with the EC 1010 by being transmitted as partof the EC 1010. Furthermore, the EC 1010 may be output from the device1040, an associated I/O support element 1062 (not shown in FIG. 10a), orother apparatus.

[0200] A preferred mode 1100 of operation of the device of FIGS. 10a, 10b, and 10 c is illustrated in FIG. 11 and begins with a resetting Step1104 of the device following a timeout or powering on of the device at1102. During the reset, the identification marker is assigned a valuecorresponding to a verification status representing the receipt of noinput for verification data for either a Secret or a biometriccharacteristic and further representing the fact that that no indicatorhas yet been output. The device then enters a repeating loop that beginsat 1106 and ends at 1116 and continues within this loop until the deviceis reset, is powered off, or deactivates after a predetermined amount oftime.

[0201] Still referring to FIG. 11, the first step in the loop preferablyincludes the determination Step 1108 whether any input representingverification data for the Secret (SVD) is received by the device. If thedetermination in Step 1108 is positive, the current verification status(VS) of the device is identified Step 1118 by comparing the Secretverification data (SVD) with the data for the Secret (SPD) prestored inthe memory of the device. The verification status identified then isrecorded by assigning Step 1120 the identification marker stored withinthe memory of the device equal to the predefined value corresponding tothe identified verification status.

[0202] If no input representing verification data for the Secret isreceived in Step 1108 or after the value of the identification marker isassigned in Step 1120, the next step in the loop preferably includes thedetermination Step 1110 whether any input representing verification datafor the biometric characteristic (BVD) is received by the device. If thedetermination in Step 1110 is positive, the current verification status(VS) of the device is identified Step 1122 by comparing the biometricverification data (BVD) with the biometric data (BPD) prestored in thememory of the device. The verification status identified then isrecorded by assigning Step 1124 the identification marker stored withinthe memory of the device equal to the predefined value corresponding tothe identified verification status.

[0203] If no input representing verification data for the biometriccharacteristic is received in Step 1110 or after the value of theidentification marker is recorded in Step 1124, the next step in theloop preferably includes the determination Step 1112 whether any inputrepresenting message data (MD) is received by the device. If thedetermination in Step 1112 is positive, the device originates Step 1126a digital signature for the message data. The digital signature for themessage data is then output Step 1128 from the device.

[0204] If no input representing message data is received in Step 1112 orafter the digital signature for the message data is output in Step 1128,a determination is then made Step 1114 of whether a signal (S) has beenor is being received by the device. If a signal is not received, thenthe loop restarts Step 1106. When a signal is received, thedetermination in Step 1114 is positive and the indicator of the currentverification status of the device is output Step 1130. As set forthabove, the indicator comprises the value of the identification markermaintained in memory within the device. Following the output of theindicator, the determination is made Step 1132 whether the indicatoroutput is the first indicator output since receipt of input representingverification data for the Secret.

[0205] If the determination in Step 1132 is positive, then theverification status is newly recorded by assigning Step 1136 a value tothe identification marker that further represents the fact that anindicator has been output since input representing verification data forthe Secret was received in Step 1108. If the determination in Step 1132is negative or after the value of the identification marker is newlyrecorded in Step 1136, the determination is made Step 1134 whether theindicator output is the first indicator output since receipt of inputrepresenting verification data for the biometric characteristic.

[0206] If the determination in Step 1134 is positive, then theverification status is newly recorded by assigning Step 1138 a value tothe identification marker that further represents the fact that anindicator has been output since input representing verification data forthe biometric characteristic was received in Step 1110. If thedetermination in Step 1134 is negative or after the value of theidentification marker is newly recorded in Step 1138, then the looprestarts Step 1106.

[0207] 6. Sixth Preferred Embodiment (Digital Signature as theIndicator)

[0208] A sixth preferred embodiment 1200 of the present invention isillustrated in FIG. 12a, wherein an EC 1210 including a message from asender 1220 is received by a recipient represented by an electronicapparatus 1230, and wherein a device 1240 receives input representingverification data (VD) 1250 at a device interface 1252. The deviceinterface 1252 includes, as appropriate, one or more of the following: auser interface such as an alphanumeric keypad, a touch screen display,or a biometric scanner for receiving input directly from the sender1220; an electrical contact; a standard electronic interface with acomputer bus; an antenna; or a communications port, such as a serialport, USB port, parallel port, infrared port or other wirelesscommunications port.

[0209] The device 1240 includes a verification component therein thatmaintains data (PD) 1270 of the sender 1220 prestored in memory 1254.The verification data 1250 and prestored data 1270 represent Secret orbiometric values. The verification component identifies at 1256 acurrent verification status of the device 1240 based on a comparison ofthe verification data 1250 with the prestored data 1270 and records thelast identified (i.e., “current”) verification status of the device 1240by assigning a value to an identification marker (IM) 1272 that isstored in memory 1274.

[0210] The device 1240 also receives at the device interface 1252 data(MD) 1222 representing the message of the EC 1210. The message data maycomprise the message itself, a message digest thereof, or the result ofsome other processing of the message (M). The device 1240 includes adigital signature component that, upon receipt of the message data 1222,obtains the value for the identification marker 1272 and modifies themessage data at 1277 as a function of this value (as used herein,“function” may include the possible function f(x)=x for a particularvalue of x).

[0211] The digital signature component then originates a digitalsignature 1299 for the modified message data (MD′) by calculating a hashvalue therefor at 1290 and then encrypting the hash value at 1292 usinga private key 1295 of a public-private key pair. For increasedreliability and trust, the private key 1295 is retained securely withinmemory 1294 so that it is never exported from the device 1240 and is notdiscoverable from outside of the device 1240. The digital signature isoriginated in accordance with the ECDSA as specified in FIPS PUB 186-2.Accordingly, the digital signature 1299 is generated using a randomnumber generator, and the hash function at 1290 is performed usingSHA-1, which generates a 20-byte output regardless of the size of theinput received. The digital signature 1299 then is output from thedevice 1240 for transmitting to the recipient as the indicator 1260 ofthe verification status of the device 1240. The digital signature 1299output from the device 1240 actually comprises the indicator of theverification status (IVS) 1260 as a result of the modification process.The indicator 1260 then is transmitted to the recipient in associationwith the EC 1210, whereby the recipient is able to identify theindicator 1260 as pertaining to the EC 1210.

[0212] The device 1240 includes a set of predefined verificationstatuses each representing a relational correspondence between theverification data 1250 and the prestored data 1270. Verificationstatuses of the set further represent whether an indicator 1260 has beenoutput from the device 1240 since the last successful verification orsince the last receipt of input representing verification data. The setalso contains an additional predefined verification status representingthe lack of input representing verification data 1250 since a resettingafter a timeout or a powering on of the device 1240. The indicator 1260output from the device 1240 is based on the last comparison of theverification data 1250 with the prestored data 1270, but only if inputrepresenting verification data 1250 has been received since theresetting of the device 1240. Otherwise, the indicator 1260 indicatesthe lack of input representing verification data 1250 since theresetting of the device 1240.

[0213] The electronic apparatus 1230 includes an interface (not shown)capable of receiving the indicator 1260. The electronic apparatus 1230also includes logic circuitry or software incorporating business logictherein for determining the verification status of the device based onthe indicator 1260 and for evaluating the EC 1210 received from thesender 1220 based on the determined verification status. In this regard,the electronic apparatus 1230 decrypts the digital signature with thepublic key, which corresponds to the private key 1295 and which may bereceived in association with the digital signature or known or obtainedbeforehand by the recipient. The recipient also modifies—and thencalculates a hash value for—the message for each one of the predefinedverification statuses of the device until the calculated hash valueequals the hash value of the decrypted digital signature. In calculatinga hash value for comparison, the electronic apparatus 1230 also performsany necessary processing to the message in order to produce the messagedata that was modified within the device 1240. When the hash valuecalculated by the recipient equals the hash value of the decrypteddigital signature, the recipient thereby determines the currentverification status of the device 1240. This determination also confirmsthe authenticity of the message of the EC 1210. Furthermore, in order tominimize consumption of resources, the set of verification statuses ofthe device is predefined to contain only a limited number ofverification statuses when this particular device 1240 of the preferredembodiment 1200 is used.

[0214] When the verification data 1250 and the prestored data 1270comprise a Secret, the predefined set of verification statuses includesfour verification statuses, comprising: a first verification statusrepresenting the lack of verification data 1250 since a resetting of thedevice; a second verification status representing a match between theverification data 1250 and the prestored data 1270, and furtherrepresenting no other indicator 1260 being output from the device 1240since the match; a third verification status representing a failed matchbetween the verification data 1250 and the prestored data 1270; and afourth verification status representing a match between the verificationdata 1250 and the prestored data 1270, and further representing theoutput of an indicator 1260 since the match. The identification marker1272 stored in memory 1274 preferably comprises one of four binarynumbers that represents the current verification status identified bythe device 1240. Of course, the correspondence between the values of theidentification marker 1272 and the predefined verification statuses ofthe device should be previously known by the recipient.

[0215] The four binary numbers respectively correspond to the fourverification statuses and include: “00” identifying the firstverification status; “01” identifying the second verification status;“10” identifying the third verification status; and “11” identifying thefourth verification status. Furthermore, the modification of the messagedata 1222 at 1277 preferably includes the embedding of the value of theidentification marker 1272 within the message data, including insertionof the value at a predefined location within, or at the beginning or endof, the message data. As also will be appreciated, the “modification” ofthe message data for one of the verification statuses may include notmodifying the message data, such as when the identification marker 1272equals “00.” Even in this case, however, the digital signature 1299identifies the verification status of the device as representing thelack of verification data 1250 being received since a resetting of thedevice. Furthermore, it will be appreciated that the digital signature1299 for the modified message neither reveals the verification data 1250nor the prestored data 1270; thus, no “shared secret” is requiredbetween the sender and the recipient in the preferred embodiment 1200.However, the recipient can infer correct knowledge of the Secret fromthe verification status.

[0216] Alternatively, when the verification data 1250 and the prestoreddata 1270 comprise biometric values, the set of predefined verificationstatuses comprises the possible percentages of match—or degrees ofdifference—between the verification data 1250 and prestored data 1270,together with a verification status representing the lack of inputrepresenting verification data 1250 since a resetting of the device1240. For example, the predefined verification statuses comprising thepercentage match of the verification data 1250 with the prestored data1270 may comprise the set of percentages ranging from 0% to 100% inincrements of, in this embodiment, 20%. Preferably each one of theverification statuses representing a percentage match also furtherrepresents whether an indicator 1260 has been output from the device1240 since the last receipt of input representing verification data1250. The identification marker 1272 stored in memory 1274 preferablycomprises the percentage match plus a flag regarding the output of theindicator 1260 as identified by the device 1240. Of course, thecorrespondence between the values of the identification marker 1272 andthe predefined verification statuses of the device 1240 should bepreviously known by the recipient. Also, in this case, the modificationof the message data 1222 at 1277 preferably includes the embedding ofthe value of the identification marker 1272 within the message data,including insertion of the value at a predefined location within, or atthe beginning or end of, the message data. As also will be appreciated,the “modification” of the message data for one of the verificationstatuses may include not modifying the message data, such as when noverification data 1250 has been received since a resetting of the device1240. Even in this case, however, the digital signature 1299 identifiesthe verification status of the device 1240 as representing the lack ofverification data 1250 being received since a resetting of the device1240. Furthermore, it will be appreciated that the digital signature1299 for the modified message neither reveals the verification data 1250nor the prestored data 1270; thus, no biometric value representing thesender's irreplaceable biometric characteristic is communicated to therecipient. However, the recipient can infer from the verification statusthe presence of the sender 1220 from the reading of the biometriccharacteristic.

[0217] A variation based on the sixth preferred embodiment 1200 of FIG.12a is shown in FIG. 12b, and includes an I/O support element 1262 fromwhich input representing the verification data 1250 and inputrepresenting the message data 1222 is received by the device 1240. TheI/O support element 1262 includes a user interface 1258 from which inputfrom the sender 1220 is received and an I/O interface 1259 thatcommunicates the input representing the verification data 1250 and inputrepresenting the message data 1222 to the device 1240. Although themessage data 1222 is shown coming from the I/O support element 1262, itis possible for some or all of the message data 1222 to originate withthe device 1240 or another apparatus (not shown). Yet an additionalvariation thereof is shown in FIG. 12c, wherein the I/O support element1262 receives the indicator 1260 being output from the device 1240. TheI/O support element 1262, in turn, transmits the indicator 1260 to theelectronic apparatus 1230. As shown, the indicator 1260 transmitted fromthe I/O support element 1262 is the same as the indicator 1260 outputfrom the device 1240. However, the indicator 1260 transmitted from theI/O support element 1262 may be packaged or embedded within anothercommunication—including additional information that is digitally signedby the I/O support element 1262.Furthermore, in FIGS. 12a, 12 b, and 12c, the EC 1210 is shown as being transmitted separate from the indicator1260. However, in the preferred embodiment of FIG. 12a and anyvariations thereof, the indicator 1260 equally may be associated withthe EC 1210 by being transmitted as part of the EC 1210. Furthermore,the EC 1210 may be output from the device 1240, an associated I/Osupport element 1262 (not shown in FIG. 12a), or other apparatus.

[0218] A preferred mode 1300 of operation of the device of FIGS. 12a, 12b, and 12 c is illustrated in FIG. 13 and begins with a resetting Step1304 of the device following a timeout or powering on of the device at1302. During the reset, the identification marker is assigned a valuecorresponding to a verification status representing the receipt of noinput of verification data and further representing the fact that thatno indicator has yet been output. The device then enters a repeatingloop that begins at 1306 and ends at 1312 and continues within this loopuntil the device is reset, is powered off, or deactivates after apredetermined amount of time.

[0219] Still referring to FIG. 13, the first step in the loop preferablyincludes the determination Step 1308 whether any input representingverification data is received by the device. If the determination inStep 1308 is positive, the current verification status (VS) of thedevice is identified Step 1314 by comparing the verification data (VD)with the data (PD) prestored in the memory of the device. Theverification status identified then is recorded by assigning Step 1316the identification marker stored within the memory of the device equalto the predefined value corresponding to the identified verificationstatus.

[0220] If no input representing verification data is received in Step1308 or after the value of the identification marker is recorded in Step1316, the next step in the loop preferably includes the determinationStep 1310 whether any input representing message data (MD) is receivedby the device. If the determination in Step 1310 is negative, the looprestarts Step 1306. If the determination in Step 1310 is positive, thedevice then modifies Step 1318 the message data based on theidentification marker. Next, the device originates Step 1320 a digitalsignature for the modified message data. The digital signature for themodified message data is then output Step 1322 from the device.Following the output of the digital signature for the modified message,the determination is made Step 1324 whether the digital signature outputis the first digital signature output since receipt of input forverification data in Step 1308. The loop restarts Step 1306 if thedetermination in Step 1324 is negative. If the determination in Step1324 is positive, then the verification status is newly recorded Step1326 by assigning a value to the identification marker that representsthe verification status indicated by the digital signature output inStep 1322, and that further represents the fact that the digitalsignature has been output. The loop then restarts Step 1306.

[0221] 7. Seventh Preferred Embodiment (Message and Indicator DigitallySigned)

[0222] A seventh preferred embodiment 1400 of the present invention isillustrated in FIG. 14a, wherein an EC 1410 including a message from asender 1420 is received by a recipient represented by an electronicapparatus 1430, and wherein a device 1440 receives input representingverification data (VD) 1450 at a device interface 1452. The deviceinterface 1452 includes, as appropriate, one or more of the following: auser interface such as an alphanumeric keypad, a touch screen display,or a biometric scanner for receiving input directly from the sender1420; an electrical contact; a standard electronic interface with acomputer bus; an antenna; or a communications port, such as a serialport, USB port, parallel port, infrared port or other wirelesscommunications port.

[0223] The device 1440 includes a verification component therein thatmaintains data (PD) 1470 of the sender 1420 prestored in memory 1454.The verification data 1450 and prestored data 1470 represent Secret orbiometric values. The verification component identifies at 1456 acurrent verification status of the device 1440 based on a comparison ofthe verification data 1450 with the prestored data 1470 and records thelast identified (i.e., “current”) verification status of the device 1440by assigning a value to an identification marker (IM) 1472 that isstored in memory 1474.

[0224] The device 1440 also receives at the device interface 1452message data (PD) 1422 representing the message (M) of the EC 1410. Themessage data 1422 may comprise the message itself, a message digestthereof, or the result of some other processing of the message. Thedevice 1440 includes a digital signature component that, upon receipt ofthe message data 1422, obtains the value for the identification marker1472 and modifies the message data at 1477 as a function of this value(as used herein, “function” may include the possible function f(x)=x fora particular value of x). The digital signature component thenoriginates a digital signature 1499 for the modified message data (MD′)by calculating a hash value therefor at 1490 and then encrypting thehash value at 1492 using a private key 1495 of a public-private keypair. For increased reliability and trust, the private key 1495 isretained securely within memory 1494 so that it is never exported fromthe device 1440 and is not discoverable from outside of the device 1440.The digital signature is originated in accordance with the ECDSA asspecified in FIPS PUB 186-2. Accordingly, the digital signature 1499 isgenerated using a random number generator, and the hash function at 1490is performed using SHA-1, which generates a 20-byte output regardless ofthe size of the input received. The digital signature 1499 then isoutput from the device 1440 together with the value of theidentification marker 1472 as the indicator 1460 of the verificationstatus (IVS) of the device 1440 for transmitting to the recipient. Thedigital signature 1499 and the indicator 1460 then are transmitted tothe recipient in association with the EC 1410, whereby the recipient isable to identify the indicator 1460 as pertaining to the EC 1410.

[0225] The device 1440 includes a set of predefined verificationstatuses each representing a relational correspondence between theverification data 1450 and the prestored data 1470. Verificationstatuses of the set further represent whether an indicator 1460 has beenoutput from the device 1440 since the last successful verification orsince the last receipt of input representing verification data. The setalso contains an additional predefined verification status representingthe lack of input representing verification data 1450 since a resettingafter a timeout or a powering on of the device 1440. The indicator 1460output from the device 1440 is based on the last comparison of theverification data 1450 with the prestored data 1470, but only if inputrepresenting verification data 1450 has been received since theresetting of the device 1440. Otherwise, the indicator 1460 indicatesthe lack of input representing verification data 1450 since theresetting of the device 1440.

[0226] The electronic apparatus 1430 includes an interface (not shown)capable of receiving the indicator 1460. The electronic apparatus 1430also includes logic circuitry or software incorporating business logictherein for determining the verification status of the device based onthe indicator 1460 and for evaluating the EC 1410 received from thesender 1420 based on the determined verification status. In this regard,the electronic apparatus 1430 decrypts the digital signature with thepublic key, which corresponds to the private key 1495 and which may bereceived in association with the digital signature 1499 or known orobtained beforehand by the recipient. The recipient also modifies—andthen calculates a hash value for—the message based on the verificationstatus identified by the indicator 1460. In calculating a hash value forcomparison, the electronic apparatus 1430 also performs any necessaryprocessing to the message in order to produce the message data that wasmodified within the device 1440. When the hash value calculated by therecipient equals the hash value of the decrypted digital signature, therecipient confirms the authenticity of the current verification statusof the device 1440 as indicated by the indicator 1460 as well asconfirms the authenticity of the message of the EC 1410.

[0227] When the verification data 1450 and the prestored data 1470comprise a Secret, the predefined set of verification statuses includesfour verification statuses, comprising: a first verification statusrepresenting the lack of verification data 1450 since a resetting of thedevice; a second verification status representing a match between theverification data 1450 and the prestored data 1470, and furtherrepresenting no other indicator 1460 being output from the device 1440since the match; a third verification status representing a failed matchbetween the verification data 1450 and the prestored data 1470; and afourth verification status representing a match between the verificationdata 1450 and the prestored data 1470, and further representing theoutput of an indicator 1460 since the match. The identification marker1472 stored in memory 1474 preferably comprises one of four binarynumbers that represents the current verification status identified bythe device 1440. Of course, the correspondence between the values of theidentification marker 1472 and the predefined verification statuses ofthe device should be previously known by the recipient.

[0228] The four binary numbers respectively correspond to the fourverification statuses and include: “00,” identifying the firstverification status; “01” identifying the second verification status;“10” identifying the third verification status; and “11” identifying thefourth verification status. Furthermore, the modification of the messagedata 1422 at 1477 preferably includes the embedding of the value of theidentification marker 1472 within the message data, including insertionof the value at a predefined location within, or at the beginning or endof, the message data. As also will be appreciated, the “modification” ofthe message data for one of the verification statuses may include notmodifying the message data, such as when the identification marker 1472equals “00.” Even in this case, however, the digital signature 1499identifies the verification status of the device as representing thelack of verification data 1450 being received since a resetting of thedevice. Furthermore, it will be appreciated that neither the digitalsignature 1499 for the modified message nor the indicator 1460 revealsthe verification data 1450 or the prestored data 1470; thus, no “sharedsecret” is required between the sender 1420 and the recipient in thepreferred embodiment 1400. However, the recipient can infer correctknowledge of the Secret from the verification status.

[0229] Alternatively, when the verification data 1450 and the prestoreddata 1470 comprise biometric values, the set of predefined verificationstatuses comprises the possible percentages of match—or degrees ofdifference—between the verification data 1450 and prestored data 1470,together with a verification status representing the lack of inputrepresenting verification data 1450 since a resetting of the device1440. For example, the predefined verification statuses comprising thepercentage match of the verification data 1450 with the prestored data1470 may comprise the set of percentages ranging from 0% to 100% inincrements of 1%. Preferably each one of the verification statusesrepresenting a percentage match also further represents whether anindicator 1460 has been output from the device 1440 since the lastreceipt of input representing verification data 1450. The identificationmarker 1472 stored in memory 1474 preferably comprises the percentagematch plus a flag regarding the output of the indicator 1460 asidentified by the device 1440. Of course, the correspondence between thevalues of the identification marker 1472 and the predefined verificationstatuses of the device 1440 should be previously known by the recipient.

[0230] Also, in this case, the modification of the message data 1422 at1477 preferably includes the embedding of the value of theidentification marker 1472 within the message data, including insertionof the value at a predefined location within, or at the beginning or endof, the message data. As also will be appreciated, the “modification” ofthe message data for one of the verification statuses may include notmodifying the message data, such as when no verification data 1450 hasbeen received since a resetting of the device 1440. Even in this case,however, the digital signature 1499 identifies the verification statusof the device 1440 as representing the lack of verification data 1450being received since a resetting of the device 1440. Furthermore, itwill be appreciated that neither the digital signature 1499 for themodified message nor the indicator 1460 reveals the verification data1450 or the prestored data 1470; thus, no biometric value representingthe sender's irreplaceable biometric characteristic is communicated tothe recipient. However, the recipient can infer from the verificationstatus the presence of the sender 1420 from the reading of the biometriccharacteristic.

[0231] A variation based on the seventh preferred embodiment 1400 ofFIG. 14a is shown in FIG. 14b, and includes an I/O support element 1462from which input representing the verification data 1450 and inputrepresenting the message data 1422 is received by the device 1440. TheI/O support element 1462 includes a user interface 1458 from which inputfrom the sender 1420 is received and an I/O interface 1459 thatcommunicates the input representing the verification data 1450 and inputrepresenting the message data 1422 to the device 1440. Although themessage data 1422 is shown coming from the I/O support element 1462, itis possible for some or all of the message data 1422 to originate withthe device 1440 or another apparatus (not shown). Yet an additionalvariation thereof is shown in FIG. 14c, wherein the I/O support element1462 receives the indicator 1460 and digital signature 1499 output fromthe device 1440. The I/O support element 1462, in turn, transmits theindicator 1460 and the digital signature 1499 to the electronicapparatus 1430.

[0232] As shown, the indicator 1460 and digital signature 1499transmitted from the I/O support element 1462 are the same as theindicator 1460 and digital signature 1486 output from the device 1440.However, the indicator transmitted from the I/O support element 1462 maybe different from the indicator output from the device 1440, so long asthe recipient is able to determine both the verification status asindicated by the indicator 1460 output from the device 1440, as well asthe bit pattern of the identification marker 1472 based on which themessage was modified. For instance, the indicator transmitted from theI/O support element 1462 may indicate not only the verification statusof the device 1440, but also a verification status of the I/O supportelement 1462 when the I/O support element 1462 itself identifies averification status. Furthermore, the indicator 1460 and digitalsignature 1499 transmitted from the I/O support element 1462 may bepackaged or embedded within another communication—including additionalinformation that is digitally signed by the I/O support element 1462.

[0233] Furthermore, in FIGS. 14a, 14 b, and 14 c, the EC 1410 is shownas being transmitted separate from the indicator 1460 and digitalsignature 1499. However, in the preferred embodiment of FIG. 14a and anyvariations thereof, the indicator 1460 and digital signature 1499equally may be associated with the EC 1410 by being transmitted as partof the EC 1410. Furthermore, the EC 1410 may be output from the device1440, an associated I/O support element 1462 (not shown in FIG. 14a), orother apparatus.

[0234] A preferred mode 1500 of operation of the device of FIGS. 14a, 14b, and 14 c is illustrated in FIG. 15 and begins with a resetting Step1504 of the device following a timeout or powering on of the device at1502. During the reset, the identification marker is assigned a valuecorresponding to a verification status representing the receipt of noinput of verification data and further representing the fact that thatno indicator has yet been output. The device then enters a repeatingloop that begins at 1506 and ends at 1512 and continues within this loopuntil the device is reset, is powered off, or deactivates after apredetermined amount of time.

[0235] Still referring to FIG. 15, the first step in the loop preferablyincludes the determination Step 1508 whether any input representingverification data is received by the device. If the determination inStep 1508 is positive, the current verification status (VS) of thedevice is identified Step 1514 by comparing the verification data (VD)with the data (PD) prestored in the memory of the device. Theverification status identified then is recorded by assigning Step 1516the identification marker stored within the memory of the device equalto the predefined value corresponding to the identified verificationstatus.

[0236] If no input representing verification data is received in Step1508 or after the value of the identification marker is recorded in Step1516, the next step in the loop preferably includes the determinationStep 1510 whether any input representing message data (MD) is receivedby the device. If the determination in Step 1510 is negative, the looprestarts Step 1506.

[0237] If the determination in Step 1510 is positive, the device thenmodifies Step 1518 the message data based on the identification marker.Next, the device originates Step 1520 a digital signature for themodified message data. The digital signature for the modified messagedata and the value of the identification marker are then output Step1522 from the device. Following the output of the digital signature forthe modified message and value of the identification marker, thedetermination is made Step 1524 whether the value of the identificationmarker output is the first value thereof output since receipt of inputrepresenting verification data in Step 1508. The loop restarts Step 1506if the determination in Step 1524 is negative. If the determination inStep 1524 is positive, then the verification status is newly recordedStep 1526 by assigning a value to the identification marker thatrepresents the verification status identified by the value of theidentification marker output in Step 1522, and that further representsthe fact that the value of the identification marker has been output.The loop then restarts Step 1506.

[0238] 8. Eighth Preferred Embodiment (Multiple Verification Data withIndicator and Message Digitally Signed)

[0239] An eighth preferred embodiment 1600 of the present invention isillustrated in FIG. 16a, wherein an EC 1610 including a message from asender 1620 is received by a recipient represented by an electronicapparatus 1630, and wherein a device 1640 receives input representingfirst verification data (VD1) 1651 and input representing secondverification data (VD2) 1653 at a device interface 1652. The deviceinterface 1652 includes, as appropriate, one or more of the following: auser interface such as an alphanumeric keypad, a touch screen display,or a biometric scanner for receiving input directly from the sender1620; an electrical contact; a standard electronic interface with acomputer bus; an antenna; or a communications port, such as a serialport, USB port, parallel port, infrared port or other wirelesscommunications port.

[0240] The device 1640 includes a verification component therein thatmaintains data prestored in memory of the device 1640. The firstprestored data (PD1) 1642 is located in memory 1641, and the secondprestored data (PD2) 1644 is located in memory 1643. The verificationcomponent identifies at 1656 a current verification status of the device1640 based on a comparison of the first verification data 1651 with thefirst prestored data 1642 and the second verification data 1653 with thesecond prestored data 1644, and records the latest (i.e., “current”)verification status of the device 1640 by assigning a value to anidentification marker (M) 1672 stored in memory 1674.

[0241] The device 1640 also receives at the device interface 1652message data (MD) 1622 representing the message (M) of the EC 1610. Themessage data 1622 may comprise the message itself, a message digestthereof, or the result of some other processing of the message. Thedevice 1640 includes a digital signature component that, upon receipt ofthe message data 1622, obtains the value for the identification marker1672 and modifies the message data at 1677 as a function of this value(as used herein, “function” may include the possible function f(x)=x fora particular value of x). The modification of the message preferablyincludes the embedding of the value of the identification marker 1672within the message data, including insertion of the value at apredefined location within, or at the beginning or end of, the messagedata. As also will be appreciated, the “modification” of the messagedata for one of the verification statuses may include not modifying themessage data.

[0242] The digital signature component then originates a digitalsignature 1699 for the modified message data (MD′) by calculating a hashvalue therefor at 1690 and then encrypting the hash value at 1692 usinga private key 1695 of a public-private key pair. For increasedreliability and trust, the private key 1695 is retained securely withinmemory 1694 so that it is never exported from the device 1640 and is notdiscoverable from outside of the device 1640. The digital signature isoriginated in accordance with the ECDSA as specified in FIPS PUB 186-2.Accordingly, the digital signature 1699 is generated using a randomnumber generator, and the hash function at 1690 is performed usingSHA-1, which generates a 20-byte output regardless of the size of theinput received. The digital signature 1699 then is output from thedevice 1640 together with the value of the identification marker 1672 asthe indicator 1660 of the verification status (IVS) of the device 1640for transmitting to the recipient. The digital signature 1699 and theindicator 1660 then are transmitted to the recipient in association withthe EC 1610, whereby the recipient is able to identify the indicator1660 as pertaining to the EC 1610.

[0243] The device 1640 includes a set of predefined verificationstatuses each representing a relational correspondence between theverification data 1651,1653 and the prestored data 1642,1644.Verification statuses of the set further represent whether an indicator1660 has been output from the device 1640 since the last successfulverification based on either or both of the first and secondverification data 1651,1653, or since the last receipt of inputrepresenting either or both of the first and second verification data1651,1653. The set also contains a predefined verification statusrepresenting the lack of input of both first and second verificationdata 1651,1653 since a resetting after a timeout or a powering on of thedevice 1640. The indicator 1660 output from the device 1640 is based onthe last respective comparison of verification data with the prestoreddata, but only if input representing the respective verification datahas been received since the resetting of the device 1640. Otherwise, theindicator 1660 indicates the lack of input for both the first and secondverification data 1651,1653 since the resetting of the device 1640.

[0244] The electronic apparatus 1630 includes an interface (not shown)capable of receiving the indicator 1660. The electronic apparatus 1630also includes logic circuitry or software incorporating business logictherein for determining the verification status of the device based onthe indicator 1660 and for evaluating the EC 1610 received from thesender 1620 based on the determined verification status. In this regard,the electronic apparatus 1630 decrypts the digital signature with thepublic key, which corresponds to the private key 1695 and which may bereceived in association with the digital signature 1699 or known orobtained beforehand by the recipient. The recipient also modifies—andthen calculates a hash value for—the message based on the verificationstatus identified by the indicator 1660. In calculating a hash value forcomparison, the electronic apparatus 1630 also performs any necessaryprocessing to the message in order to produce the message data that wasmodified within the device 1640. When the hash value calculated by therecipient equals the hash value of the decrypted digital signature, therecipient confirms the authenticity of the current verification statusof the device 1640 as indicated by the indicator 1660 as well asconfirms the authenticity of the message of the EC 1610.

[0245] When either of the first or second verification data1651,1653—and the prestored data therefor—comprise a Secret, thepredefined set of results for the comparison for such includes fourpossible outcomes, comprising: a first outcome representing the lack ofverification data since a resetting of the device 1640; a second outcomerepresenting a match between the verification data and the prestoreddata, and further representing no other indicator 1660 being output fromthe device 1640 since the match; a third outcome representing a failedmatch between the verification data and the prestored data; and a fourthoutcome representing a match between the verification data and theprestored data, and further representing the output of an indicator 1660since the match.

[0246] When either of the first or second verification data1651,1653—and the prestored data therefor—represent a biometriccharacteristic, the predefined set of results for the comparison forsuch produces a result preferably out of a predefined number of possibleoutcomes. Each outcome represents a possible percentage of match—ordegree of difference—between the verification data and prestored datathat is allowed, together with a verification status representing thelack of input for verification data since a resetting of the device1640. For example, the predefined outcomes comprising the percentagematch of the verification data with the prestored data may comprise theset of percentages ranging from 0% to 100% in increments of 1%.Preferably each one of the outcomes representing a percentage match alsofurther represents whether an indicator 1660 has been output from thedevice 1640 since the last receipt of input representing verificationdata.

[0247] The identification marker 1672 is stored in memory 1674 andcomprises a value representing one of the set of predefined verificationstatuses of the device 1640. The set of predefined verification statusespreferably comprises all of the possible combinations of outcomes fromthe respective comparisons for the first and second verification data1651,1653. Of course, the correspondence of the possible values for theidentification marker 1672 with the predefined verification statuses ofthe device 1640 should be previously known by the recipient. Moreover,none of the verification statuses actually reveal any of theverification data 1651,1653 or the prestored data 1642,1644; thus, no“shared secret” is required between the sender 1620 and the recipient,and no biometric value representing the sender's irreplaceable biometriccharacteristic is communicated to the recipient. However, the recipientcan infer from the verification status both the correct knowledge of theSecret and the presence of the sender from the reading of the biometriccharacteristic.

[0248] A variation based on the eighth preferred embodiment 1600 of FIG.16a is shown in FIG. 16b, and includes an I/O support element 1662 fromwhich input representing the first and second verification data1651,1653 and input representing the message data 1622 is received bythe device 1640. The I/O support element 1662 includes a user interface1658 from which input from the sender 1620 is received and an I/Ointerface 1659 that communicates the input representing the first andsecond verification data 1651,1653 and input representing the messagedata 1622 to the device 1640.

[0249] Although the message data 1622 is shown coming from the I/Osupport element 1662, it is possible for some or all of the message data1622 to originate with the device 1640 or another apparatus (not shown).Yet an additional variation thereof is shown in FIG. 16c, wherein theI/O support element 1662 receives the indicator 1660 and digitalsignature 1699 output from the device 1640. The I/O support element1662, in turn, transmits the indicator 1660 and the digital signature1699 to the electronic apparatus 1630.

[0250] As shown, the indicator 1660 and digital signature 1699transmitted from the I/O support element 1662 are the same as theindicator 1660 and digital signature 1686 output from the device 1640.However, the indicator transmitted from the I/O support element 1662 maybe different from the indicator output from the device 1640, so long asthe recipient is able to determine both the verification status asindicated by the indicator 1660 output by the device 1640, as well asthe bit pattern of the identification marker 1672 based on which themessage was modified. For instance, the indicator transmitted from theI/O support element 1662 may indicate not only the verification statusof the device 1640, but also a verification status of the I/O supportelement 1662 when the I/O support element 1662 itself identifies averification status. Furthermore, the indicator 1660 and digitalsignature 1699 transmitted from the I/O support element 1662 may bepackaged or embedded within another communication—including additionalinformation that is digitally signed by the I/O support element 1662.

[0251] Furthermore, in FIGS. 16a, 16 b, and 16 c, the EC 1610 is shownas being transmitted separate from the indicator 1660 and digitalsignature 1699. However, in the preferred embodiment of FIG. 16a and anyvariations thereof, the indicator 1660 and digital signature 1699equally may be associated with the EC 1610 by being transmitted as partof the EC 1610. Furthermore, the EC 1610 may be output from the device1640, an associated I/O support element 1662 (not shown in FIG. 16a), orother apparatus.

[0252] A preferred mode 1700 of operation of the device of FIGS. 16a, 16b, and 16 c is illustrated in FIG. 17 and begins with a resetting Step1704 of the device following a timeout or powering on of the device at1702. During the reset, the identification marker is assigned a valuecorresponding to a verification status representing the receipt of noinput of any verification data and further representing the fact thatthat no indicator has yet been output. The device then enters arepeating loop that begins at 1706 and ends at 1714 and continues withinthis loop until the device is reset, is powered off, or deactivatesafter a predetermined amount of time.

[0253] Still referring to FIG. 17, the first step in the loop preferablyincludes the determination Step 1708 whether any input representing thefirst verification data (VD1) is received by the device. If thedetermination in Step 1708 is positive, the current verification status(VS) of the device is identified Step 1716 by comparing the firstverification data (VD1) with the first data (PD1) prestored in thememory of the device. The verification status identified then isrecorded by assigning Step 1718 the identification marker stored withinthe memory of the device equal to the predefined value corresponding tothe identified verification status. If no input representing the firstverification data is received in Step 1708 or after the value of theidentification marker is recorded in Step 1718, the next step in theloop preferably includes the determination Step 1710 whether any inputrepresenting the second verification data (VD2) is received by thedevice. If the determination in Step 1710 is positive, the currentverification status (VS) of the device is identified Step 1720 bycomparing the second verification data (VD2) with the second data (PD2)prestored in the memory of the device. The verification statusidentified then is recorded by assigning Step 1722 the identificationmarker stored within the memory of the device equal to the predefinedvalue corresponding to the identified verification status.

[0254] If no input representing the second verification data is receivedin Step 1710 or after the value of the identification marker is recordedin Step 1722, the next step in the loop preferably includes thedetermination Step 1712 whether any input representing message data (MD)is received by the device. If the determination in Step 1712 isnegative, the loop restarts Step 1706.

[0255] If the determination in Step 1712 is positive, the device thenmodifies Step 1724 the message data based on the identification marker.Next, the device originates Step 1726 a digital signature for themodified message data. The digital signature for the modified messagedata and the value of the identification marker are then output Step1728 from the device. Following the output of the digital signature forthe modified message and value of the identification marker, thedetermination is made Step 1730 whether the value of the identificationmarker output is the first value thereof output since receipt of inputrepresenting the first verification data in Step 1708.

[0256] If the determination in Step 1730 is positive, then theverification status is newly recorded Step 1734 by assigning a value tothe identification marker that represents the verification statusidentified by the value of the identification marker output in Step1728, and that further represents the fact that the value of theidentification marker has been output. If the determination in Step 1730is negative or after the value of the identification marker is newlyrecorded in Step 1734, the next step in the loop preferably includes thedetermination Step 1732 whether the value of the identification markeroutput is the first value thereof output since receipt of inputrepresenting the second verification data in Step 1710.

[0257] If the determination in Step 1732 is positive, then theverification status is newly recorded Step 1736 by assigning a value tothe identification marker that represents the verification statusidentified by the value of the identification marker output in Step1728, and that further represents the fact that the value of theidentification marker has been output. If the determination in Step 1732is negative or after the value of the identification marker is newlyrecorded in Step 1736, the loop then restarts Step 1706.

[0258] 9. Ninth Preferred Embodiment (Multiple Verification Data withDigital Signature as Indicator)

[0259] A ninth preferred embodiment 1800 of the present invention isillustrated in FIG. 18a, wherein an EC 1810 including a message from asender 1820 is received by a recipient represented by an electronicapparatus 1830, and wherein a device 1840 receives input representingfirst verification data (VD1) 1851 and input representing secondverification data (VD2) 1853 at a device interface 1852. The deviceinterface 1852 includes, as appropriate, one or more of the following: auser interface such as an alphanumeric keypad, a touch screen display,or a biometric scanner for receiving input directly from the sender1820; an electrical contact; a standard electronic interface with acomputer bus; an antenna; or a communications port, such as a serialport, USB port, parallel port, infrared port or other wirelesscommunications port.

[0260] The device 1840 includes a verification component therein thatmaintains data prestored in memory of the device 1840. The firstprestored data (PD1) 1842 is located in memory 1841, and the secondprestored data (PD2) 1844 is located in memory 1843. The verificationcomponent identifies at 1856 a current verification status of the device1840 based on a comparison of the first verification data 1851 with thefirst prestored data 1842 and the second verification data 1853 with thesecond prestored data 1844, and records the latest (i.e., “current”)verification status of the device 1840 by assigning a value to anidentification marker (IM) 1872 stored in memory 1874. In this casewherein comparisons of more than one input of verification data is made,the identification marker 1872 comprises a value assigned to a firstcomparison marker representing the result of the first comparison and avalue assigned to a second comparison marker representing the result ofthe second comparison.

[0261] The device 1840 also receives at the device interface 1852message data (MD) 1822 representing the message (M) of the EC 1810. Themessage data 1822 may comprise the message itself, a message digestthereof, or the product of some other processing of the message. Thedevice 1840 includes a digital signature component that, upon receipt ofthe message data 1822, obtains the value for the identification marker1872 and modifies the message data at 1877 as a function of this value(as used herein, “function” may include the possible function f(x)=x fora particular value of x). The modification of the message preferablyincludes the embedding of the value of the identification marker 1872within the message data, including insertion of the value at apredefined location within, or at the beginning or end of, the messagedata. As also will be appreciated, the “modification” of the messagedata for one of the verification statuses may include not modifying themessage data.

[0262] The digital signature component then originates a digitalsignature 1899 for the modified message data (MD′) by calculating a hashvalue therefor at 1890 and then encrypting the hash value at 1892 usinga private key 1895 of a public-private key pair. For increasedreliability and trust, the private key 1895 is retained securely withinmemory 1894 so that it is never exported from the device 1840 and is notdiscoverable from outside of the device 1840. The digital signature isoriginated in accordance with the ECDSA as specified in FIPS PUB 186-2.Accordingly, the digital signature 1899 is generated using a randomnumber generator, and the hash function at 1890 is performed usingSHA-1, which generates a 20-byte output regardless of the size of theinput received. The digital signature 1899 then is output from thedevice 1840 as the indicator 1860 of the verification status (IVS) ofthe device 1840 for transmitting to the recipient. The digital signature1899 output from the device 1840 actually comprises the indicator of theverification status (IVS) 1860 as a consequence of the modificationprocess. The current outcome of the first comparison (results of VD1 andPD1 comparison) is also output as a result (R) 1896. The indicator 1860and result 1896 then are transmitted to the recipient in associationwith the EC 1810, whereby the recipient is able to identify theindicator 1860 and result 1896 as pertaining to the EC 1810.

[0263] The device 1840 includes a set of predefined verificationstatuses each representing a relational correspondence between theverification data 1851,1853 and the prestored data 1842,1844.Verification statuses of the set further represent whether an indicator1860 has been output from the device 1840 since the last successfulverification based on either or both of the first and secondverification data 1851,1853, or since the last receipt of inputrepresenting either or both of the first and second verification data1851,1853. The set also contains a predefined verification statusrepresenting the lack of input of both first and second verificationdata 1851,1853 since a resetting after a timeout or a powering on of thedevice 1840. The indicator 1860 output from the device 1840 is based onthe last respective comparisons of verification data with the prestoreddata, but only if input representing verification data has been receivedsince the resetting of the device 1840. Otherwise, the indicator 1860indicates the lack of input for both the first and second verificationdata 1851,1853 since the resetting of the device 1840.

[0264] The electronic apparatus 1830 includes an interface (not shown)capable of receiving the indicator 1860. The electronic apparatus 1830also includes logic circuitry or software incorporating business logictherein for determining the verification status of the device based onthe indicator 1860 and for evaluating the EC 1810 received from thesender 1820 based on the determined verification status. In this regard,the electronic apparatus 1830 decrypts the digital signature with thepublic key, which corresponds to the private key 1895 and which may bereceived in association with the digital signature 1899 or known orobtained beforehand by the recipient. The recipient also modifies—andthen calculates a hash value for—the message based on the result 1896and for each possible outcome of the second comparison until thecalculated hash value equals the hash value of the decrypted digitalsignature. In calculating a hash value for comparison, the electronicapparatus 1830 also performs any necessary processing to the message inorder to produce the message data that was modified within the device1840. When the hash value calculated by the recipient equals the hashvalue of the decrypted digital signature, the recipient therebydetermines the current verification status of the device 1840. Thisdetermination also confirms the authenticity of the message of the EC1810. Furthermore, in order to minimize consumption of resources, thesecond set of outcomes for the second comparison (VD2 with PD2) ispredefined to contain only a limited number of outcomes. For instance,the first verification data and prestored data therefor preferablyrepresent a biometric characteristic, and the second verification dataand prestored data therefor preferably represent a Secret.

[0265] When either of the first or second verification data1851,1853—and the prestored data therefor—comprise a Secret, thepredefined set of outcomes for the comparison for such includes fourpossible outcomes, comprising: a first outcome representing the lack ofverification data since a resetting of the device 1840; a second outcomerepresenting a match between the verification data and the prestoreddata, and further representing no other indicator 1860 being output fromthe device 1840 since the match; a third outcome representing a failedmatch between the verification data and the prestored data; and a fourthoutcome representing a match between the verification data and theprestored data, and further representing the output of an indicator 1860since the match.

[0266] When either of the first or second verification data1851,1853—and the prestored data therefor—represent a biometriccharacteristic, the predefined set of outcomes for the comparison forsuch produces a result preferably out of a predefined number of possibleoutcomes. Each outcome represents a possible percentage of match—ordegree of difference—between the verification data and prestored datathat is allowed, together with a verification status representing thelack of input for verification data since a resetting of the device1840. For example, the predefined outcomes comprising the percentagematch of the verification data with the prestored data may comprise theset of percentages ranging from 0% to 100% in increments of 1%.Preferably each one of the outcomes represents a percentage match alsofurther represents whether an indicator 1860 has been output from thedevice 1840 since the last receipt of input representing verificationdata.

[0267] The identification marker 1872 is stored in memory 1874 andcomprises a value representing one of the set of predefined verificationstatuses of the device 1840. The set of predefined verification statusespreferably comprises all of the possible combinations of outcomes fromthe respective comparisons for the first and second verification data1851,1853. Of course, the correspondence of the possible values for theidentification marker 1872 with the predefined verification statuses ofthe device 1840 should be previously known by the recipient. Moreover,none of the verification statuses actually reveal any of theverification data 1851,1853 or the prestored data 1842,1844; thus, no“shared secret” is required between the sender 1820 and the recipient,and no biometric value representing the sender's irreplaceable biometriccharacteristic is communicated to the recipient. However, the recipientcan infer from the verification status both the correct knowledge of theSecret and the presence of the sender.

[0268] A variation based on the ninth preferred embodiment 1800 of FIG.18a is shown in FIG. 18b, and includes an I/O support element 1862 fromwhich input representing the first and second verification data1851,1853 and input representing the message data 1822 is received bythe device 1840. The I/O support element 1862 includes a user interface1858 from which input from the sender 1820 is received and an I/Ointerface 1859 that communicates the input representing the first andsecond verification data 1851,1853 and input representing the messagedata 1822 to the device 1840. Although the message data 1822 is showncoming from the I/O support element 1862, it is possible for some or allof the message data 1822 to originate with the device 1840 or anotherapparatus (not shown). Yet an additional variation thereof is shown inFIG. 18c, wherein the I/O support element 1862 receives the indicator1860 and the result 1896 output from the device 1840. The I/O supportelement 1862, in turn, transmits the indicator 1860 and the result 1896to the electronic apparatus 1830.

[0269] As shown, the indicator 1860 and result 1896 transmitted from theI/O support element 1862 are the same as the indicator 1860 and result1896 output from the device 1840. However, the result transmitted fromthe I/O support element 1862 may be different from the result outputfrom the device 1840, so long as the recipient is able to determine thebit pattern of the result 1872 based in part on which the message wasmodified. For instance, the result transmitted from the I/O supportelement 1862 may indicate not only the result of the comparison of thefirst verification data input into the device 1840, but also averification status of the I/O support element 1862 when the I/O supportelement 1862 itself identifies a verification status. Furthermore, theindicator 1860 and result 1896 transmitted from the I/O support element1862 may be packaged or embedded within another communication—includingadditional information that is digitally signed by the I/O supportelement 1862.

[0270] Furthermore, in FIGS. 18a, 18 b, and 18 c, the EC 1810 is shownas being transmitted separate from the indicator 1860 and result 1896.However, in the preferred embodiment of FIG. 18a and any variationsthereof, the indicator 1860 and result 1896 equally may be associatedwith the EC 1810 by being transmitted as part of the EC 1810.Furthermore, the EC 1810 may be output from the device 1840, anassociated I/O support element 1862 (not shown in FIG. 18a), or otherapparatus.

[0271] A preferred mode 1900 of operation of the device of FIGS. 18a, 18b, and 18 c is illustrated in FIG. 19 and begins with a resetting Step1904 of the device following a timeout or powering on of the device at1902. During the reset, the identification marker is assigned a valuecorresponding to a verification status representing the receipt of noinput of any verification data and further representing the fact thatthat no indicator has yet been output. The device then enters arepeating loop that begins at 1906 and ends at 1914 and continues withinthis loop until the device is reset, is powered off, or deactivatesafter a predetermined amount of time.

[0272] Still referring to FIG. 19, the first step in the loop preferablyincludes the determination Step 1908 whether any input representing thefirst verification data (VD1) is received by the device. If thedetermination in Step 1908 is positive, the current verification status(VS) of the device is identified Step 1916 by comparing the firstverification data (VD1) with the first data (PD1) prestored in thememory of the device. The verification status identified then isrecorded by assigning Step 1918 the identification marker stored withinthe memory of the device equal to the predefined value corresponding tothe identified verification status. If no input representing the firstverification data is received in Step 1908 or after the value of theidentification marker is recorded in Step 1918, the next step in theloop preferably includes the determination Step 1910 whether any inputrepresenting the first verification data (VD1) is received by thedevice. If the determination in Step 1910 is positive, the currentverification status (VS) of the device is identified Step 1920 bycomparing the second verification data (VD2) with the second data (PD2)prestored in the memory of the device. The verification statusidentified then is recorded by assigning Step 1922 the identificationmarker stored within the memory of the device equal to the predefinedvalue corresponding to the identified verification status.

[0273] If no input representing the second verification data is receivedin Step 1910 or after the value of the identification marker is recordedin Step 1922, the next step in the loop preferably includes thedetermination Step 1912 whether any input representing message data (MD)is received by the device. If the determination in Step 1912 isnegative, the loop restarts Step 1906.

[0274] If the determination in Step 1912 is positive, the device thenmodifies Step 1924 the message data based on the identification marker.Next, the device originates Step 1926 a digital signature for themodified message data. The digital signature for the modified messagedata and the value of the result for the first comparison are thenoutput Step 1928 from the device. Following the output of the digitalsignature for the modified message and value of the result of the firstcomparison, the determination is made Step 1930 whether the digitalsignature is the first output since receipt of input representing thefirst verification data in Step 1908. If the determination in Step 1930is positive, then the verification status is newly recorded Step 1934 byassigning a value to the identification marker that represents theverification status identified by the digital signature marker output inStep 1928, and that further represents the fact that the digitalsignature has been output.

[0275] If the determination in Step 1930 is negative or after the valueof the identification marker is newly recorded in Step 1934, the nextstep in the loop preferably includes the determination Step 1932 whetherthe digital signature is the first output since receipt of inputrepresenting the second verification data in Step 1910. If thedetermination in Step 1932 is positive, then the verification status isnewly recorded Step 1936 by assigning a value to the identificationmarker that represents the verification status identified by the digitalsignature output in Step 1928, and that further represents the fact thatthe digital signature has been output. If the determination in Step 1932is negative or after the value of the identification marker is newlyrecorded in Step 1936, the loop then restarts Step 1906.

[0276] C. Data Formats, Embodiments and Implementations of the PresentInvention

[0277] In accordance with all of the aspects of the present invention,the device comprises hardware, software and/or firmware and,specifically, comprises a computer chip, an integrated circuit, acomputer-readable medium having suitable software therein, or acombination thereof. The device further may comprise a physical objectsuch as a hardware token or an embedded token, the token containing sucha computer chip, integrated circuitry, software, or combination thereof.If the device is a hardware token, it preferably takes the form of aring or other jewelry; a dongle; an electronic key; a card, such as anIC card, smart card, debit card, credit card, ID badge, security badge,parking card, or transit card; or the like. If the device is an embeddedtoken, it preferably takes the form of a cell phone; a telephone; atelevision; a personal digital assistant (PDA); a watch; a computer;computer hardware; or the like. The device preferably includes a deviceinterface comprising a port—including a wireless communications port, aserial port, a USB port, a parallel port, or an infrared port—or someother physical interface for communicating with at least an externalelectronic apparatus, whether contact or contactless. The device alsomay include a trusted platform module (TPM) comprising hardware andsoftware components providing increased trust in a platform, as setforth and described in the TCPA Documents cited above. Some of the abovedevices require use of an I/O support element to enable the device toreceive message data or verification data. Some of the devices requirean I/O support element to receive specific types of verification databut not others. Some of the devices require use of an I/O supportelement to transmit information regarding verification statuses, digitalsignatures, and messages to recipients of the ECs. Some of the devicesare self-contained, which means that they can generate and transmitmessages, digital signatures, and indicators of verification statuswithout the use of external apparatuses; some devices, althoughself-contained, are capable of interacting with such externalapparatuses, such as an I/O support element, if desired. An I/O supportelement may take the form of any number of different apparatuses,depending upon the particular application in which it is used anddepending upon the type of device with which it interacts.

[0278] For higher security applications, the device—or the device incombination with an I/O support element—preferably includes thefollowing components: a keypad (alphanumeric), interactive display, orother type of user data entry mechanism (collectively referred to hereinas “User Interface”) that allows the sender of an EC to compose ormodify a message; a User Interface for inputting Secret verificationdata (it should be noted that the User Interface for generating ormodifying a message may, but does not have to, be the same as the UserInterface for the entry of the Secret verification data); a display forshowing the message and/or Secret to the sender of the EC using thedevice; a scanner or reader for receiving at least one type of biometricverification data; memory for securely storing the Secret(s), prestoredbiometric data, and the private key (PrK); a processor or circuitry forperforming the various comparisons and for identifying a verificationstatus of the device; a processor or circuitry for generating ororiginating digital signatures; and a means for outputting informationfrom the device and transmitting it to the electronic apparatus.Preferably, the device also includes memory for storing and exportingthe public key (PuK) associated with the particular private key (PrK),and for storing additional user information such as account information,user ID's, and the like. For lower security applications, not all of theabove elements are necessary.

[0279] To this point, the discussion of the present invention hasfocused on the flow of data into and out of the device and themanipulation of such data performed by components within the device orin communication with the device. This section provides further detailregarding, for example, preferred database formats and exemplary datavalues and structures for verification data, prestored data,verification statuses, and identification markers and indicators ofverification status. This section also illustrates preferredmethodologies for identifying verification statuses when verificationdata represents a Secret, biometric characteristic, or a combination ofboth. Additionally, this section illustrates the functional aspects of apreferred computer chip that may be used as the device or as part of adevice of the present invention. Finally, this section provides severalspecific implementations of a device—in this case an IC card—adapted foruse in accordance with the present invention.

[0280] 1. Prestored Data, Verification Data, and Indicators ofVerification Status

[0281] a. Record Formats for Prestored Data

[0282] As shown in FIGS. 20a, 20 b, and 20 c, the prestored data of anauthorized user of a device (generally referred to as PD) may bemaintained in suitable records 2000 a, 2000 b, and 2000 c, respectively,within a database of the device. As shown in FIG. 20a, for simpleapplications in which the device is adapted to receive and process onlya Secret, such as a PIN 2003, record 2000 a would simply contain the“value” 2005 for the Secret Prestored Data (SPD) 2042 (or referred togenerically as PD 2070). As shown in FIG. 20b, for slightly more complexapplications in which the device is adapted to receive and process onlyone specified type 2002 of biometric data 2007, record 2000 b wouldsimply contain the “value” 2009 for the applicable Biometric PrestoredData (BPD) 2044 (also referred to generically as PD 2070).

[0283] As shown in FIG. 20c, for other applications in which the deviceis adapted to receive and process more than one specified type ofverification data, the record 2000 c includes a list of the possibleverification data types 2002 representing both a Secret and a biometriccharacteristic. Each type 2002 of verification data (whether Secret orbiometric) has associated therewith a corresponding pre-set identifier2004 and a corresponding unique value 2006 comprising the prestored data2070 therefor. The specific identifiers 2004 associated with particulardata types 2002, as shown in FIG. 20c, are arbitrary and may beformatted or established to conform with any industry standard orconvention now or hereinafter developed (such as, for example, thestandards set forth in Biometric Information Management and Security forthe Financial Services Industry, Document Number X9.84-2000 WD, AmericanNational Standards Institute, 2000, which is incorporated herein byreference and which is available for download athttp://webstore.ansi.org). Further, the list of types 2002 of data shownin FIG. 20c, is only intended to be exemplary and, in practice, record2000 c may include more, less, or different specific types 2002 of data.

[0284] In addition, although the types 2002 of data are shown in records2000 a, 2000 b, and 2000 c for ease of reference and explanation, it isnot necessary that the information that appears in the column showingthe types 2002 actually be maintained in these records if therelationship between each data type 2002 and its correspondingidentifier 2004 is otherwise known. Except for the prestored data(values 2005,2008) for the PINs, which is conventionally includes a 4-10digit alphanumeric string, the values 2009,2010 associated with eachtype 2002 of biometric data will generally be a numeric valuecorresponding to a digital representation of an authorized user'sbiometric characteristic. For example, the current F.B.I. standard forelectronic fingerprint scans is “40 point minutiae.” Such a value may beobtained by an appropriate and conventional biometric scanner capable ofscanning and converting such scan into a digital representation of theparticular biometric data type 2002. Generally, for any particularbiometric data type 2002, it is preferably that the same standard,scale, or convention be used at both the personalization stage of thedevice, when such data is input into the device for the purpose ofcreating the prestored data, as well as each time verification data islater input into the device for the purpose of identifying averification status. If no data has been prestored for comparison with aparticular type 2002 of data, then the corresponding value 2012 for thatdata type 2002 is set to zero, null, or comparable equivalent value.

[0285] b. Verification Data Formats Input into the Device

[0286] As shown in FIG. 21a, for simple applications in which the deviceis adapted to receive and process only a Secret (again, such as a PIN),it is preferable that the verification data 2150 comprise SecretVerification Data (SVD) 2151 having a value 2102 input by the sender ofan EC when using the device. As shown in FIG. 21b, for slightly morecomplex applications in which the device is adapted to receive andprocess only one specified type of biometric verification data, it ispreferable that the verification data 2150 comprise BiometricVerification Data (BVD) 2153 having a value 2104 input in response, to ascan of a biometric characteristic provided by the sender when using thedevice. Finally, as shown in FIG. 21c, for other applications in whichthe device is adapted to receive and process more than one specifiedtype of verification data, whether Secret or biometric, it is preferablethat the verification data 2150 comprise both an identifier 2106 and acorresponding value 2108. The identifier 2106 indicates the type ofverification data being input into the device, and, hence, indicates theprestored data the device will need to reference for comparisonpurposes. Although not shown, it should be understood that instead ofusing identifiers, it is possible to use software or device commands orinstructions in combination with the input of verification data 2150 tonotify the device of the particular type of the verification data 2150being input.

[0287] c. Comparison Process and Identification of Verification Status

[0288] Referring now to FIGS. 22, 23a, 23 b, and 24, several exemplaryprocesses by which a device compares the verification data withprestored data and thereby identifies the verification status are setforth in greater detail. Again, as shown in FIG. 22, and referringinitially to simple applications in which the device is, adapted toreceive and process only verification data for a Secret, the devicefirst determines if input representing verification data (e.g. as shownin Step 308 in FIG. 3) has in fact been received and, if so, determines(Step 2202) whether such verification data is for a Secret. Ifverification data for the Secret is not received, then the devicemaintains Step 2204 the current verification status (the start-updefault value of which is “No PIN entered”).

[0289] If verification data for a Secret is received, then the deviceretrieves Step 2206 the corresponding prestored data (SPD), e.g., value2005 from record 2000 a in FIG. 20a. Next, the device compares Step 2208the input value with the prestored data value. If the result (Rs) of thecomparison is that the values are equal, then the device identifies Step2210 the verification status as “PIN match.” If the result (Rs) of thecomparison is that the values are not equal, then the device identifiesStep 2212 the verification status as “PIN no match.” Furthermore,although FIG. 22 shows the verification statuses in a descriptive format(e.g., “No PIN entered;” “PIN match;” and “PIN no match”), it should beunderstood that the device, preferably, sets an identification marker(IM) to an arbitrary value that directly maps to a respectiveverification status which, in this simple example, is also equal to theresult of the comparison (Rs). A few possible examples of equivalentidentification marker values are illustrated in FIG. 25a. Nevertheless,it should be obvious to one skilled in the art that innumerabledifferent types, conventions, or formats for suitable equivalentverification statuses corresponding to those listed in FIG. 25a may bechosen within the scope of the present invention. As shown in FIG. 25a,a first identification marker comprising a Secret verification result(Rs₁)) 2502 is in cardinal number format. A second identification markercomprising a Secret verification result (Rs₂) 2504 is in binary format.Additionally, a third identification marker comprising a Secretverification result (Rs₃) 2506 that is shown is merely a differentcharacter string representation of the verification statuses listed inthe first column of FIG. 25a. Referring back to FIG. 22, the resultingidentification marker values shown in Steps 2210 and 2212 use the secondconvention described above.

[0290] Referring now to FIGS. 23a and 23 b, for slightly more complexapplications in which the device is adapted to receive and process onlyone specified type of biometric verification data, the device firstdetermines Step 2302 that biometric verification data has, in fact, beenreceived. If no biometric verification data has been received, then thedevice maintains Step 2304 the current verification status (the start-updefault value of which is “No BIO input”). If the device has receivedbiometric verification data, then the device retrieves Step 2306 thecorresponding prestored data (BVD) (e.g. value 2009 from record 2000 bin FIG. 20b). In biometric data comparisons, unlike in Secret datacomparisons, it is preferred that the result (Rb) of the comparisoncomprise the degree or percentage of match (or difference) between theverification data and the prestored data. Thus, in preferredembodiments, the device identifies Step 2308 a a verification status bydividing the biometric verification data by the prestored data to obtaina percentage match between the two values and assigning the result (Rb)to the identification marker.

[0291] As shown in FIG. 23b, the device may alternatively obtain apercentage difference between the two values by calculating Step 2308 bthe absolute value of the difference between the two values and dividingthat number by the prestored data, and then assigning the result (Rb) tothe identification marker. Several examples of equivalent biometricidentification marker values are illustrated in FIG. 26; however, itshould be obvious to one skilled in the art that many different types,conventions, or formats for identification marker values showing degreeor percentage of match or difference between the biometric verificationdata and the prestored data (e.g., such as those set forth in FIG. 26)may be chosen within the scope of the present invention. For example, afirst identification marker comprising a biometric verification result(Rb₁) 2602 is a percentage value (to 2 digits) corresponding to thedegree of match or difference between the two values (with thecalculated number substituted for the “##”). A second identificationmarker comprising a biometric verification result (Rb₂) 2604 is adecimal value (to 2 digits) corresponding to the degree of match ordifference between the two values. A third identification markercomprising biometric verification result (Rb₃) 2606 is a characterstring associated with the corresponding verification status in thefirst column of the figure.

[0292] As has been described previously, in the preferred embodiment,the device outputs an indicator of the verification status based onbiometric verification data in the form of a degree (or percentage) ofmatch or degree (or percentage) of difference between the biometricverification data and the prestored data. By providing the verificationstatus in this manner, the electronic apparatus (or recipient) isallowed to determine, based on its own logic or business rules, whetherthe degree of match obtained and provided by the device meets a requiredsecurity threshold for a particular business purpose or application.This enables the device to be used easily with different recipients,each with its own threshold requirements for biometric verificationdata. Alternatively, it should be understood that the device itselfcould be pre-programmed or pre-hardwired to determine within the devicewhether the biometric verification data qualifies as a “match” or “nomatch” with the prestored data relative to an arbitrarily determinedthreshold—in which case, its identification marker would be similarmerely to that for a comparison of verification data for a Secret.

[0293] Referring now to FIG. 24, for other applications in which thedevice is adapted to receive and process Secret and biometricverification data, the device first initiates Step 2402 a loop for thepurpose of processing each input for those applications in which morethan one type of verification data is received. In the first step withinthe loop, the device determines Step 2404 whether verification data hasbeen received. If verification data has not been received, then thedevice maintains Step 2406 the current verification status (which atstart-up is “No PIN entered; No BIO entered”). If verification data hasbeen received, then the device retrieves Step 2410 the prestored data(2006 from FIG. 2000c) corresponding with the identifier (2106 from FIG.21c) for such verification data. As an aside and as stated previously,another embodiment allows a device or computer command sent with theverification data to indicate the type of verification data being inputwithout the use of an identifier 2106 (as shown in FIG. 21c). Next, thedevice determines Step 2412, based on the identifier (or command input),whether the verification data represents a Secret or a biometriccharacteristic.

[0294] If the verification data represents a Secret, then the devicecompares Step 2414 the verification data with the correspondingprestored data for such Secret. If the values are equal, then the deviceidentifies Step 2416 the result of the comparison as a “match” and, inthis example, sets Rs equal to a value of “01” (using the binaryconvention from FIG. 25a). The loop then restarts Step 2408. If thevalues are not equal, then the device identifies Step 2416 the resultsof the comparison as a “no match” and, in this example, sets Rs equal toa value of “10” (again using the binary convention from FIG. 25a). Theloop then restarts at Step 2408. On the other hand, if the devicedetermines that the verification data represents a biometriccharacteristic, then the device identifies Step 2420 the verificationstatus by comparing the verification data with the correspondingprestored data and calculating a percentage match therebetween. In thisregard, the device sets Rb for the particular type of biometricverification data (designated by ###) equal to the value of thepercentage match. The loop then restarts at Step 2408. In this example,the value of the identification marker (IM) corresponding with theverification status includes the value for Rs as well as the values foreach Rb for each biometric verification type.

[0295] Several examples using specific numbers will help explain thisprocess. In the first example, suppose a PIN and one type of biometricverification data, such as a right handprint, is entered into the deviceby a sender of an EC who is using the device. In this example (using theconventions discussed above with regard to FIGS. 20c and 21 c and withregard to column 2504 of FIG. 25a and column 2702 of FIG. 26) a suitableverification status is represented by an identification marker includingthe following value:

[0296] 001,10,012,90 (with or without the commas)

[0297] This identification marker indicates a verification status inwhich an incorrect PIN was received and a right handprint having a 90%degree of match was received.

[0298] In a second example, suppose three types of biometricverification data (a right thumb, a left thumb, and a right iris scan)are entered. In this second example (again using the same conventions),a suitable verification status is represented by an identificationmarker including the following value:

[0299] 002,95,007,93,018,87 (with or without the commas)

[0300] This identification marker indicates a verification status inwhich a right thumbprint bad a 95% match, a left thumbprint had a 93%match, and a right iris scan produced an 87% match.

[0301] In an alternate embodiment, after performing the above steps, thedevice identifies the verification status as an identification markercontaining every possible identifier 2004 (or some subset thereof fromFIG. 20c) followed by its corresponding Rs or Rb value. Thus, eventhough an input is not provided for every single type of verificationdata, the identification marker nevertheless includes all identifiers2004 and their corresponding Rs and Rb values. For those types for whichno input is received, the corresponding value for Rs or Rb is itsdefault value preferably comprising zero or null, or a suitableequivalent. In this third example, a suitable verification status isrepresented as an identification marker of:

[0302] 001/01/002,00,003,00,004,0.25,005,00,006,0.96, . . . 024,0.95

[0303] Assuming that the “ . . . ” merely includes each identifierbetween 007 and 023 followed by a “00” (i.e., no verification datainputs corresponding with identifiers 007 through 023), theidentification marker in this example indicates a verification status inwhich a correct PIN was input, a right middle fingerprint had a 25%match, a right pinky fingerprint had a 96% match, and a DNA scan had a95% match. Just for comparison purposes, unlike the previous examples,this example uses the conventions for Rb discussed above with regard tocolumn 2604 of FIG. 26.

[0304] In another alternative embodiment, it is possible to eliminateall of the identifiers 2004 from the identification marker if therecipient knows what convention is used by the device, including thesequence of presenting each verification data type within theidentification marker value or data stream. For example, using bothconventions as described above for all twenty three identifiers (column2504 of FIG. 25a for the Rs value and column 2602 of FIG. 26 for the Rbvalues in the first identification marker below, and column 2504 of FIG.25a for the Rs value and column 2604 of FIG. 26 for the Rs values in thesecond identification marker below) and assuming that the order ofverification data types is the same as the twenty-three identifiers 2004in FIG. 20c, the identification marker for the above-describedverification status could be presented, alternatively, as follows:0100000.25000.9600000000000000000000000000000000000.95 or010000250096000000000000000000000000000000000095

[0305] Each identification marker above identifies a verification statusin which a correct PIN was input, a right middle fingerprint had a 25%match, a right pinky fingerprint had a 96% match, and a DNA scan had a95% match.

[0306] 2. Associating Specific Sender Approval for EC

[0307] It is also possible and advantageous for the device to provideadditional information to the recipient of an EC as to whether theverification status of the device is in a “persistent” state or whetherthe verification status applies specifically to the EC with which theindicator of verification status is associated. Such information can beused by the recipient to determine whether the sender of the EC inputthe correct Secret for a previous message or whether the correct Secretwas input as specific approval or authorization of the transaction orrequest contained within the EC that is digitally signed. The sameadvantages apply in the case of a biometric characteristic.

[0308] For example, as stated above, for devices configured only toreceive verification data for a Secret, such as a PIN, there are threeverification statuses, or “states”, that can be identified by theidentification marker using the format of FIG. 25a: no PIN entered(Rs=00); correct PIN (Rs=01); and incorrect PIN (Rs=10). In accordancewith this additional feature of the present invention, an additional“state” is added to these three as shown more fully in FIG. 25b. Thisadditional state represents that a correct PIN was entered, but thatsince then, an indicator of the verification status was output or adigital signature was generated in association with an EC. This fourthstate may be shown using any of the formats previously discussed,including a cardinal number format shown in column 2508 of FIG. 25b; abinary format shown in column 2510 of FIG. 25b; and a character stringformat shown in column 2512 of FIG. 25b. Using the binary format, thefourth state is identified whenever an indicator is output or a digitalsignature is generated with the identification marker equaling “01” bysetting, thereafter, the identification marker equal to “11”.

[0309] Alternatively, the device maintains a counter or “digitalsignature flag” (referred to hereinafter generically as “DSFlag”). Inthis regard, the DSFlag is initially set to zero and counts to one ormore each time an indicator of verification status is output from or adigital signature is generated by the device. Thereafter, the DSFlagremains at one (or continues counting by one) for each indicator outputor digital signature generated until verification data again is receivedby the device, after which the DSFlag is reset to zero. In this case,the value of the DSFlag is incorporated into the value of theidentification marker as an additional bit of information. For example,possible values of an identification marker thus include the following,wherein “/” separates the binary value of Rs and the correspondingDSFlag value for purposes of illustration: 00/0 (no PIN input; no IVS orDS output); 00/1 (no PIN input; IVS or DS output); 01/0 (PIN match; noIVS or DS output since PIN match); 01/1 (PIN match; IVS or DS outputsince PIN match); 10/0 (PI no match; no IVS or DS output); and 10/1 (PINno match; IVS or DS output).

[0310] For a device configured to receive one type of biometricverification data only, the device preferably includes a DSFlag as partof the identification marker in similar manner to the methodology justdescribed. For example, for a device that originates digital signaturesand is only capable of receiving and processing one particular type ofbiometric verification data, the identification marker includes thedegree of match as well as the value of the DSFlag. Thus, if the senderof an EC had submitted a thumbprint, which was determined to have a 90%match, and if no digital signature had been generated, a suitable valueof the identification marker is “90/0” (with the “/” merely to indicatethe separation of the two values), with the value of “90” for Rbindicating the degree of match and the value of “0” for the DSFlagindicating that no digital signature had been generated since lastreceipt of verification data. Conversely, in the above example, if oneor more digital signatures have been generated by the device since thethumbprint scan was submitted to the device, the identification markerwould be “90/1” (or in the case of a counter, “90/x” where “x” is anynumber greater than 0).

[0311] For devices capable of receiving multiple types of verificationdata input (Secret and/or biometric), it is preferable for eachcomparison result (R) for each type of verification data to have its ownDSFlag. In this situation, every time a digital signature is originated,all of the DSFlags are set to one (or otherwise incremented as describedabove); however, each time additional verification data is received bythe device, the DSFlag for that particular type of verification data isset to zero. For transmission of information to the electronic apparatusin this scenario, it is preferred to include the particular identifier,as discussed previously. Using the example from the previous section, asuitable identification marker appears as:

[0312] 001/01,1/002,00,1/003,00,1/004,0.25,0,005,00,1/006,0.96,1, . . .024,0.95,1

[0313] This identification marker indicates a verification status inwhich a correct Secret was input, a right middle fingerprint had a 25%match, a right pinky fingerprint had a 96% match, a DNA scan had a 95%match, and the right middle fingerprint was entered since the lastdigital signature was generated by the device.

[0314] Turning now to FIG. 27, a table illustrates a hypothetical seriesof actions (primarily inputs of different types of verification data)into a device of the present invention and the resulting change (if any)to the value of the identification marker. In this example, the devicemaintains a PIN, a digitized value for the right thumbprint(identifier=002) of an authorized user of the device, and a digitizedversion of the right retina (identifier=016) of an authorized user ofthe device. In addition, in this example, the identification marker (IM)of the device comprises the Rs value, the Rb(002) value, DSFlag(002)value, Rb(016) value, and DSFlag(016) value. The identification markeruses the two digit binary convention for the value of Rs (i.e., fromcolumn 2510 from FIG. 25b), a two-digit percentage match convention forthe values of Rb(002) and Rb(016) (from column 2602 from FIG. 26), andbinary values for the DSFlag associated with each biometric verificationdata type. Thus, the DSFlag values are either “0”—indicating nogeneration of a digital signature or output of an indicator of theverification status since the particular type of biometric verificationdata was received, or “1”—indicating generation of a digital signatureor output of an indicator since the particular type of biometricverification data was received.

[0315] A series of thirteen actions is illustrated in sequence in thefirst column of the table of FIG. 27. The impact of each of theseactions upon the device and, more specifically, upon the identificationmarker of the device, which identifies the current verification statusof the device, is shown horizontally across the remaining columns of thetable. In the first action, the device is activated, turned on, orotherwise reset. This action causes each of the values that make up theidentification marker to reset to their default values of zero, asshown. In the second action, an incorrect PIN is entered, which causesthe value of Rs to change to “10.” A subsequent correct PIN entry intothe device, switches the Rs value to “01.” The generation of a digitalsignature, output of the value of the identification marker, or otheroutput of the verification status of the device causes the value of Rsto switch to “11” and both of the DSFlags to toggle to “1.” It should benoted that the value of Rs that was included within the output of thefourth action step was the “01” (from the previous row of the table,which was the “current” value of Rs at the time of the output). Asillustrated by the fifth action, a second generation of a digitalsignature, output of the value of the identification marker, or otheroutput of the verification status of the device has no effect upon thevalue of identification marker; however, it should be noted that thevalue of Rs and of the DSFlags will be different from the values thatwere output during the fourth action.

[0316] A correct PIN input as the sixth action sets the value of Rs to“01,” but noticeably has no impact on the DSFlags for the rightthumbprint and right retina. In the seventh action, a right thumbprintis provided to the device and results in an 85% match with the prestoredright thumbprint value. This causes the value of Rb(002) to be set to“85” and the value of DSFlag(002) to be set to “0.” In the eighthaction, a right retina scan result is provided to the device and resultsin a 90% match with the prestored value. This causes the value ofRb(016) to be set to “90” and also the value of DSFlag(016) to be set to“0.”

[0317] Still referring to FIG. 27, the ninth action is a thirdgeneration of a digital signature, output of the identification marker,or other output of the verification status of the device including theidentification marker that was in effect after the eighth action, whichcauses Rs to switch to “11” and both of the DSFlags to toggle back to“1.” In the tenth action, a second right thumbprint is provided to thedevice, which results in an 88% match, which changes the value ofRb(002) to “88” and the value of DSFlag(002) to “0.” An incorrect PINentry at this point, in the eleventh action, merely changes the value ofRs to “10.” In the twelfth action, the fourth generation of a digitalsignature, output of the identification marker, or other output of theverification status of the device causes DSFlag(002) to toggle back to“1” but has not effect upon the Rs value or upon the DSFlag(016) value,which is already set to “1.” In the thirteenth action, a second rightretina provided to the device, which results in an 89% match, changesthe value of Rb(016) to “89” and switches the value of DSFlag(016) backto “0.” In the fourteenth action (not specifically shown), a resetsignal to the device resets all of the values back to those shown afterthe first action.

[0318] Additional features and benefits of the present invention,including those relating to identification markers and indicators ofverification status, will become apparent from the following discussionsregarding specific devices and implementations of the present invention.

[0319] 3. Computer Chip Design

[0320] Turning now to FIG. 28, a preferred computer chip 50 that may beused in conjunction with an IC card, PDA, cell phone, personal computer,or other device in accordance with the present invention is illustrated.As shown, the computer chip 50 receives power 52, a clock input 54, anda reset or master clear input 56 from an external source 90. Thecomputer chip 50 is also connected to ground 58 and exchanges input andoutput data 60 through external source 90. The external source 90 may bepart of the IC card, PDA, cell phone, personal computer or other devicein which the computer chip 50 is installed or it may be part of an I/Osupport element (not shown) with which the IC card, PDA, cell phone,personal computer, or other device is in communication, as the case maybe.

[0321] Internally, the computer chip 50 includes an I/O router 62, acentral controller 64, a memory location 66 for securely storing aprivate key of a public-private key pair, a memory location 68 forstoring the corresponding public key of the public/private key pair, adedicated public/private key generator circuit 70, a private keydestruction circuit 72, a memory location 65 for storing a defaultprestored message, a digital signature circuit 71 (which includes a hashfunction circuit 73, a random number generator 74, and an encryptioncircuit 75), a memory location 76 for prestoring data (Secret and/orbiometric data), a selection multiplexer 78 for retrieving selectedprestored data from memory location 76, a memory location 80 for storingvarious account and other user information, a selection multiplexer 82for retrieving selected information from memory location 80, a memorylocation 83 for storing the current verification status (preferably inthe form of an identification marker (IM)) of the computer chip 50,which includes the value of Rs (for the Secret) and the values for eachRb (for each biometric verification data type stored within the device50) and the values for the DSFlags corresponding with the Rs and Rbvalues), and a selection multiplexer 84 for reading and writing to thememory location 83.

[0322] Preferably, the computer chip 50 is designed with the followingcapabilities: the ability to store data securely and permanently(especially the private key); the ability to create a public-private keypair on the chip on a one-time only basis using a random number producedwithin the chip from the random number generator 74; and the ability tooriginate digital signatures, when requested, using a random numberproduced within the chip from the random number generator 74 inaccordance with FIPS PUB 186-2. The computer chip 50 further preferablyis resistant to tampering and is immune to Differential Power Attacksand other physical analysis. The prestored data for the Secretpreferably also is protected from exhaustive search attacks. One methodof “protecting” the private key is by designing the computer chip 50with the destruct circuit 72, which destroys the private key whentriggered by any tampering or attempted theft of the private key byelectronic, physical, and other known means. Under such circumstances,the destruct circuit 72 renders the computer chip 50 useless bypreventing the computer chip 50 from being able to generate furtherdigital signatures and by destroying the information retained in memorylocation 66.

[0323] Still referring to FIG. 28, the computer chip 50 also includesnon-modifiable operating software either loaded into the chip duringmanufacture or permanently etched into read-only memory (ROM) on thechip 50. Such software enables the computer chip 50 to respond to andact upon a specific set of commands. Such commands enable, for example,the computer chip 50 to be personalized. Personalization includes theinput and prestoring of data for a Secret, a biometric characteristic,user name, and account number(s). Preferably, the prestored data for theSecret is capable of being changed, upon successful input of the currentSecret verification data. The biometric prestored data, however,preferably is permanent once loaded into memory.

[0324] The software further includes a command that causes the keygeneration circuit 70 to create a unique public-private key pairdirectly within the computer chip 50 on a one-time only basis. As statedpreviously, the private key is stored securely in memory location 66.The public key is stored in memory location 68. The software includes acommand that enables the public key to be exported from the computerchip 50. The command to export the public key may be executable multipletimes or one time only, depending upon whether strict control overaccess to the public key is desired. The software also includes acommand that notifies the computer chip 50 that verification data isbeing input. Optionally, separate commands (or separate informationincluded with the command) are used to indicate whether the verificationdata being input is for a Secret or a biometric characteristic and, iffor a biometric characteristic, the biometric type. Preferably, thecomputer chip 50 also automatically identifies a verification statuswhenever it receives verification data.

[0325] The software further includes a command that notifies thecomputer chip 50 that message data is being input. In many situations,it is necessary or desirable for the message data input or provided tothe computer chip 50 to incorporate specific account information orother user data maintained in memory location 80 on the computer chip50. There are generally two techniques for extracting such informationfrom memory location 80 and including it within the message data sent tothe computer chip 50.

[0326] In the first technique, all of the account and other userinformation is extracted from the computer chip 50 and the user isprompted through a display to select the appropriate account or userinformation to be included as part of the message to be digitally signedusing the computer chip 50. A message data command then is sent to thecomputer chip 50 for the origination of a digital signature, with theselected account or user information included in the message data. Forexample, when the computer chip 50 is used in an IC card in conjunctionwith a reader or other I/O support element, the I/O support elementsends a command to the computer chip 50 for the extraction of allaccount and user information. The user then selects the appropriateaccount or user information from a display provided by the I/O supportelement to be included as part of the message to be digitally signedusing the computer chip 50. Thereafter a message data command is sent tothe computer chip 50 for the origination of a digital signature, withthe selected account or user information included in the message data.

[0327] In the second technique, the message data command provided to thecomputer chip 50 includes one or more “null fields” or other appropriate“tags” which identify a particular account field or user informationfield, but in which no value is supplied. In response to the tag, thecomputer chip 50 searches content addressable memory to identify acorresponding field maintained in memory. Upon location of thecorresponding field, the computer chip 50 supplies the value of suchfield in the message data in substitution for the null value of the tag.With this methodology, each data cell containing account or userinformation in memory location 80 has its own tag or content address.Preferably, such tags or content addresses are standardized so thataccount or user information can be correctly stored in memory location80 and easily retrieved using a tag when later needed. Such tags mayinclude XML tags.

[0328] For example, a message data command could be sent to the computerchip 50 in which the message data contains a null field or tagrequesting that <user name> be inserted into a particular locationwithin the text of the message data. Whenever such message data isprovided to the computer chip 50, the computer chip 50 automaticallycompletes the message data by inserting, in this case, the “user name”stored in the third cell of memory location 80 of the chip 50.Preferably, a tag could be used to extract and insert any of the variousfield values (e.g., credit card account number; banking account number;user name; employer account number; web site account number, etc.)maintained in memory location 80 of the computer chip 50.

[0329] Once the message data is “completed” with all requested accountand user information using one of the above techniques, such messagedata is then ready for: modification by the current verification statusof the computer chip (using the value of IM); calculation of the hashvalue for the modified message data; encryption of the hash value togenerate a digital signature; and output of the digital signature.

[0330] Alternatively, the computer chip 50 generates a digital signaturein the same manner using a prestored message in memory location65—rather than imported message data—in response to a suitable commandto generate a digital signature.

[0331] As will be appreciated, a computer chip including components andfunctionality described above, and which is used in providing averification status in accordance with the present invention, is itselfnovel and nonobvious and, accordingly, such a computer chip indeedcomprises an aspect of the present invention.

[0332] 4. Specific Implementations of the Present Invention

[0333] FIGS. 29-33 (with frequent reference back to FIG. 28) illustratehow a single IC card 95, configured to function in accordance with thepresent invention and containing a suitable computer chip 50 (such asdescribed above with reference to FIG. 28), may be used in manydifferent applications and settings by a suspect user 46 of the IC card95. The structure of the IC card 95 is conventional in that it has thecomputer chip 50 embedded therein and surface contacts for enablingcommunication between an IC card reader and the computer chip 50 in theIC card 95. The surface contacts are ISO/IEC 7816 compliant. It is alsopossible to have an ISO/IEC 14443 compliant proximity card or acombination card capable of both 7816 and 14443 operations.

[0334] For purposes of these examples, it is assumed that the computerchip 50 (as shown in FIG. 28) already contains a unique public/privatekey pair created in the manner previously described. It is furtherassumed that a PIN (the Secret in these examples) and digitized versionsof the authorized user's right thumbprint, right retina, and voice printhave been input and prestored in memory location 76 (cells 001, 002,016, and 020 respectively) of the chip 50 (again, as shown in FIG. 28).It is also assumed that the authorized user's name, credit card accountnumber, checking account number, relevant employee ID number forbuilding and computer access, and website broker account number havebeen suitably prestored in memory location 80 for access as needed usingan appropriate tag contained within message data provided to the IC card95 from an external source, as discussed above. Additionally, it isassumed that the public key stored on the computer chip 50 has beenprovided to the authorized user's employer, credit card account company,bank, and broker, each of which has, in turn, associated in its owndatabase the public key with the authorized user's account. For purposesof the present examples, we will also assume that the computer chip 50outputs the value for the identification marker (IM), which is a datastring containing the value of Rs using the convention as set forth incolumn 2504 of FIG. 25a (i.e., no PIN (Rs=00), correct PIN and not usedfor IVS or DS (Rs=01), and incorrect PIN (Rs=10). The value for theidentification marker further includes the type identifier (0xx) and thevalue of Rb (in the format of a two-digit percentage match (xx) as setforth in column 2602 of FIG. 26) for every biometric verification datatype. Furthermore, the identification marker includes a respectiveDSFlag associated with the Rs value and with each Rb value.

[0335] Now, referring specifically to FIG. 29, a first exampleillustrates the IC card 95 being used by the suspect user 46. In thisfirst example, the suspect user 46 presents the IC card 95 to gainaccess to a parking area 2902. The parking area 2902 is secured by aparking gate 2904, which has an arm 2906 and which is controlled by aparking gate controller 2908. In turn, the parking gate controller 2908is in communication with an IC card reader 2910. Although shown asseparate from the parking gate 2904, the controller 2908 and the IC cardreader 2910 could, in fact, be physically installed within the housingof the parking gate 2904.

[0336] To get the arm 2906 to lift, the suspect user 46 inserts the ICcard 95 into the reader 2910 (or positions the card near the reader incase of 14443 operations). As this is a relatively low security parkingarea 2902, the IC card reader 2910 does not have an associated keypad orbiometric scanner; thus, there is no means by which the suspect user 46can input any verification data. Correspondingly, access to the parkingarea is not dependent upon any particular verification status of the ICcard 95. The parking gate controller 2908 opens the parking gate 2906merely upon proper presentation of the IC card 95, which ispre-registered with the parking gate controller 2908. Preferably,pre-registration involves the authorized user of the card providing hisname (“user name”) as retained in the memory 80 (as shown in FIG. 28) ofthe computer chip 50 to the parking gate controller 2908 or, conversely,having the operator of the parking gate 2904 (e.g., the authorizeduser's employer or agent) “approve” the IC card 95 for use with theparking gate system by inputting an employee account number into memorylocation 80 (as shown in FIG. 28) of the computer chip 50. For improvedsecurity, the authorized user of the card 95 also provides his publickey (retained on the chip 50) to the parking gate controller 2908, whichassociates the user's name or employee account number (hereinaftergenerally referred to as “user information”) therewith.

[0337] When the IC card 95 is inserted into the card reader 2910 (orbrought into proximity to the card reader 2910), the card reader 2910 isinitialized. Initialization of the card reader 2910 is conventional andis accomplished either by the card reader 2910 physically detecting anIC card 95, or by the IC card 95 outputting a “reset” message to thecard reader 2910 as part of its start-up protocol when it first receivespower from the card reader 2910. Once the IC card 95 receives power, theidentification marker and all DSFlags for the PIN and each applicablebiometric type are reset. Alternatively, all such values may be resetwhen power is removed from the card 95.

[0338] Following initialization, the card reader 2910 sends a messageinput command to the IC card 95. At a minimum, the message input commandincludes a tag requesting user information, such as “user name” or“employee account number” from the appropriate data field in memorylocation 80 (as shown in FIG. 28). In this example, there is noadditional message data other than the tag.

[0339] Once the message input command is received by the IC card 95, thecomputer chip 50 (as shown in FIG. 28) on the IC card 95 retrieves therequested user information from memory location 80 (as shown in FIG.28), with such user information becoming part of the message data;retrieves the current value of the identification marker; modifies themessage data with the value of the identification marker by pre-pendingthe value to the message data; calculates a hash value of the modifiedmessage data; encrypts the hash value to generate a digital signature;and exports the digital signature, requested user information, and valueof the identification marker to the card reader 2910, which forwardssuch data on to the controller 2908 for processing.

[0340] Thereafter, the controller 2908 first compares the requested userinformation (name or employee account number) received from the IC card95 with a list of authorized names or authorized employee accountnumbers maintained in its database. For low security having no regardfor authentication, the controller 2908 opens the parking gate 2906 ifthe user information received from the IC card 95 matches one of theauthorized names or authorized employee account numbers in its database.For higher security to guard against a counterfeit IC card, thecontroller 2908 decrypts the digital signature received from the IC card95 using the public key associated with the matching user information.If the decrypted hash value from the digital signature matches a hashvalue calculated based on the user information (i.e., message data)provided by the IC card 95, as modified by the value of theidentification marker received from the IC card 95, then the controller2908 determines that the IC card 95 from which the digital signature isreceived contains the unique private key associated with the user whopre-registered with the operator of the parking gate 2904, and lifts theparking gate arm 2906the decision in this case to raise the gate beingbased on Factor A Entity Authentication.

[0341] Turning now to FIGS. 30 and 31, the same IC card 95 may be usedby the suspect user 46 first to gain access into secure building 3002and then into secure room 3102, which is located within the securebuilding 3002. As shown in FIG. 30, one IC card reader 3004 is mountednext to the secure entrance 3010 into the building 3002. This IC cardreader 3004 includes an alphanumeric keypad 3006 and a display screen3008. The IC card reader 3004 is in electronic communication with abuilding security controller 3014, which controls the locking mechanism3012 of the entrance 3010. Inside the building, as shown in FIG. 31,another IC card reader 3104 is mounted on the wall next to secure door3110. This IC card reader 3104 includes a retina scanner 3106 and adisplay 3108. Likewise, this IC card reader 3104 is in electroniccommunication with the building security controller 3114, which controlsthe locking mechanism 3112 of the door 3110. If the parking area 2902(from FIG. 29) is part of the same facility as secure building 3002, itis possible that parking gate controller 2908 and building securitycontrollers 3014, 3114 are the same apparatus, part of the same computersystem, or share the same database of information regarding theauthorized user and public key for IC card 95.

[0342] First, with regard to FIG. 30, for access into the securebuilding 3002, the IC card 95 is inserted into the IC card reader 3004(or brought into proximity to the card reader 3004). The reader 3004 isinitialized in much the same way as the card reader 2910 in FIG. 29. Theidentification marker and all DSFlags are reset when power is firstsupplied to the IC card 95.

[0343] Once initialized, the card reader 3004, using the display 3008,prompts the suspect user 46 to input a PIN. Once the PIN is enteredusing the keypad 3006, the card reader 3004 transmits the same, not tothe building security controller 3014, but directly to the IC card 95.

[0344] Once the IC card 95 receives the PIN verification data, thecontroller 64 on the computer chip 50 (as shown in FIG. 28) retrievesthe prestored PIN data from memory location 76 (cell 001) and comparesthe two values (Factor B Entity Authentication). A match/no-matchdetermination is made by the controller 64, which identifies theverification status as either Rs=01 (match) or Rs=10 (no match).

[0345] After a suitable but brief delay, which is programmed into thecontrols of the card reader 3304, the card reader 3004 sends a messageinput command to the IC card 95. As was described previously in relationto FIG. 29, the message input command includes a “tag” requesting userinformation (e.g. “user name” or “employee account number”) from theappropriate data field in memory location 80 (as shown in FIG. 28).Again, it is assumed that the message data comprises the tag only and noadditional information.

[0346] Once the message input command is received by the IC card 95, thecomputer chip 50 on the IC card 95 retrieves the requested userinformation from memory location 80 (as shown in FIG. 28); retrieves thecurrent value of the identification marker; modifies the userinformation (i.e., message data) with the value of the identificationmarker by pre-pending the value to the user information; calculates ahash value of the modified user information to generate a digitalsignature; encrypts the hash value; and exports the digital signature,requested user information, and value of the identification marker tothe card reader 3004. The computer chip 50 (as shown in FIG. 28) thenincrements the value of all of the DSFlags to “1”. Equivalently, thecomputer chip 50 only increments the value of the DSFlags to “1” for thespecific verification data types for which any verification data inputhas been received since powering on of the card 95.

[0347] The digital signature, value of the identification marker, anduser information received by the card reader 3004 are communicated tothe building security controller 3014. The building security controller3014 first confirms that the user information matches either anauthorized name or an authorized employee account number for access tothe building 3002. If so, the building security controller 3014 thendecrypts the digital signature using the public key associated with thematching authorized user information. If the decrypted hash value fromthe digital signature matches a hash value calculated based on the userinformation received from the IC card 95, as modified by the value ofthe identification marker received from the IC card 95, then thebuilding security controller 3014 determines that the IC card 95 fromwhich the digital signature is received contains the unique private key.Finally, the building security controller 3014 checks the verificationstatus indicated by the value of the identification marker to determinewhether the suspect user 46 of the IC card 95 is in fact the authorizeduser of the IC card 95. If the indicated verification status representsa match (i.e., value of Rs=01), the building security controller 3014infers that the suspect user 46 is the authorized user, and then sends asignal to the locking mechanism 3012 to unlock the entrance and/or openthe door 3010.

[0348] For access into the secure room 3102 of FIG. 31, the IC card 95is inserted into the IC card reader 3104 (or brought into proximity tothe card reader 3104). The reader 3104 is initialized in much the sameway as the card reader 3004, with the identification marker and allDSFlags being reset when power is first supplied to the IC card 95. Onceinitialized, the card reader 3104, using the display 3108, prompts thesuspect user 46 to place his right eye before the scanner 3106. Theretina scanner 3106 scans the right eye of the suspect user 46 andobtains a digitized version thereof. The card reader 3104 then transmitsthe biometric verification data (which includes an identifier and avalue of the digitized scan of the right retina), not to the buildingsecurity controller 3114, but to the IC card 95 for comparison.

[0349] Once the biometric verification data is received by the IC card95, the controller 64 (as shown in FIG. 28) determines the type ofbiometric verification data received (based on the identifier),retrieves the corresponding prestored biometric data for the authorizeduser's right retina from memory location 76 (cell 016), and compares thetwo values (Factor C Entity Authentication). A degree of matchdetermination/calculation is made by the controller 64, which setsRb(016) to a two-digit number corresponding with the percentage match(again, as shown in FIG. 28).

[0350] After a suitable but brief delay, the card reader 3104 sends amessage input command to the IC card 95. As was described previously,the message input command includes a tag requesting user informationfrom the appropriate data field in memory location 80. Again, it isassumed that the message data comprises the tag only and no additionalinformation.

[0351] Once the message input command is received by the IC card 95, thecomputer chip 50 on the IC card 95 retrieves the requested userinformation from memory location 80; retrieves the current value of theidentification marker (including therein the value of Rb(016) and thevalue of the DSFlag(016), which was reset to zero when the card wasinserted into the card reader 3104); modifies the user information withthe value of the identification marker by pre-pending the value to theuser information, calculates a hash value of the modified userinformation; encrypts the hash value to generate a digital signature;and exports the digital signature, requested user information, and valueof the identification marker to the card reader 3104. The computer chip50 then increments the value of all of the DSFlags to “1.”

[0352] The digital signature, user information, and value of theidentification marker received from the IC card 95 are then communicatedby the card reader 3104 to the building security controller 3114. Thebuilding security controller 3114 first confirms that the userinformation received from the IC card 95 matches an authorized user nameor employee account number for access to the room 3102. If so, thebuilding security controller 3114 then decrypts the digital signatureusing the public key associated with the matching user information. Ifthe decrypted hash value from the digital signature matches a hash valuecalculated based on the user information received from the IC card 95,as modified by the value of the identification marker received from theIC card 95, then the building security controller 3114 determines thatthe IC card 95 from which the digital signature is received contains theunique private key. Finally, the building security controller 3114checks the verification status indicated by the value of theidentification marker to determine whether the suspect user 46 is infact the authorized user of the IC card 95. In this regard, if thedegree of match between the value for the scanned retina and theprestored value for the retina of the authorized user meets a thresholdrequirement (e.g. 90% match or better) set by the building securitycontroller 3114, then the building security controller 3114 infers thatthe suspect user 46 is the authorized user and sends a signal to thelocking mechanism 3112 to unlock and/or open the door 3110.

[0353] The building security controller 3114 may include business logicthat denies access to the room 3102 if there is a “perfect” or 100%match between the scanned retina and the prestored retina, since such acomparison likely indicates a fraudulently input verification data. Ifthe degree of match received from the card 95 does not exceed therequired threshold set by the building security controller 3114 for thisroom 3102, an additional retina scan may be requested and the aboveprocedure repeated. If the IC card 95 was not removed from the cardreader 3104, and if the IC card 95 generates a digital signature beforea new retina scan is taken or successfully transmitted into the IC card95, the verification status output by the card 95 will include theDSFlag for the right retina set to a value of “1,” which signals thebuilding security controller 3114 that a new retina scan was not inputor correctly received by the IC card 95. When a new retina scan is takenand transmitted to the IC card 95, the DSFlag for the right retina(DSFlag(016)) is reset to zero. Since retina scans of the same eye willgenerally vary slightly with each scan (as do most scans of other typesof biometric information), the building security controller 3114 will bealert to the potential of a fraudulent biometric verification datareceived by the IC card 95 when a new degree of match determination isexactly identical to a previous determination for the same biometriccharacteristic from the same IC card 95.

[0354] Even if the initial degree of match received from the card 95exceeds the required threshold set by the building security controller3114 for this room 3102, the building security controller 3114 maynevertheless request a follow-up retina scan from the suspect user 46simply for the purpose of determining if the biometric input wasfraudulent (i.e., is the follow-up degree of match identical to theinitial degree of match?). The building security controller 3114 mayalso include business logic that denies access to the room 3102 if thereis a “perfect” or 100% match between the scanned retina and theprestored retina, since such a comparison also likely indicates afraudulently input verification data. Referring to FIG. 32a, the suspectuser 46 now sits at his desk to access his personal computer 3202. Thecomputer 3202 is conventional in that it includes a keyboard 3204, amonitor 3206, and a mouse 3208. The computer 3202 also includes a cardreader 3210, which exchanges data with the computer 3202 through asuitable port (e.g., serial, parallel, USB, etc.) of the computer 3202.The card reader 3210 is similar to those discussed above and is capableof exchanging information with an IC card 95 when inserted therein (orbrought within proximity thereof). In the present example, the computer3202 also includes a microphone 3212 for receipt of audio input, such asthe voice of the suspect user 46. Although it is possible to prevent thecomputer 3202 from powering on without a proper IC card 95 inserted intothe card reader 3210, the present example assumes that the computer 3202will power on and “boot up” to a security screen (using suitablesoftware installed on the computer 3202), but that no substantiveaccess, such as to programs or databases maintained on, or to theoperating system of, the computer 3202 is enabled until the suspect user46 is authenticated. Alternatively, the building security controller3114 may also request additional PIN and/or bio input if there suspicionof fraudulent input.

[0355] After powering on, the computer 3202 prompts, on a securityscreen displayed on the monitor 3206, the suspect user 46 to insert theIC card 95 into card reader 3210, to enter a PIN into a suitable dataentry window also displayed on the screen, and to state (audibly) hisname—first name, middle initial, and last name—for the purpose ofobtaining a voiceprint.

[0356] When the IC card 95 is inserted into the reader 3210, the reader3210 is initialized (as described previously) and the power supplied tothe card 95 causes the identification marker and all of the DSFlags onthe computer chip 50 to be reset. Once the PIN has been entered usingthe keyboard 3204 and once the suspect user 46 states his name into themicrophone 3212, the computer 3202 transmits both the PIN and adigitized version of the voiceprint, via the card reader 3210, to the ICcard 95. The card reader 3210 transmits the value of the PIN anddigitized voiceprint along with an identifier (e.g., 001 for the PIN and020 for the voiceprint) for each to identify to the card 95 the type andorder of the verification data input.

[0357] Upon receipt of the PIN and biometric verification data by the ICcard 95, the controller 64 on the computer chip 50 (referring back toFIG. 28) first determines the type of verification data received basedon the identifiers and then retrieves the appropriate prestored datafrom memory location 76. In this example, the controller 64 firstretrieves the prestored data for the PIN from memory location data cell001 in memory location 76, and then compares the value with the value ofthe PIN verification data received from the card reader 3210 (Factor BEntity Authentication). A match/no-match determination is made by thecontroller 64, which sets the value of the Rs as either “01” (match) or“10” (no match). Next, the controller 64 retrieves the prestored datafor the authorized user's voiceprint from data cell 020 in memorylocation 76, and then compares this value with the digitized voiceprintreceived from the card reader 3210 (Factor C Entity Authentication). Adegree of match determination/calculation is made by the controller 64,which sets the value of Rb(020) to a two-digit number corresponding tothe percentage match.

[0358] After a suitable but brief delay, the computer 3202 then sends amessage input command to the IC card 95 via the card reader 3210. Inthis case, the message input command includes a tag requesting userinformation from the appropriate data field in memory location 80(again, as shown in FIG. 28). Again, it is assumed that the message datacomprises the tag only and no additional information.

[0359] Once the message input command is received by the IC card 95, thecomputer chip 50 on the IC card 95 retrieves the requested authorizeduser information (as the message data) from memory location 80;retrieves the current value of the identification marker (which includesthe value of Rs and the value of DSFlag(001), which was reset to zerowhen the card was inserted into the card reader 3210, and which alsoincludes the value of Rb(020) and the value of the DSFlag(020), whichwas also reset to zero), modifies the message data with theidentification marker by pre-pending the value to the message data,calculates a hash value of the modified message data, encrypts the hashvalue to generate a digital signature, and exports the digitalsignature, requested user information, and value of the identificationmarker to the card reader 3210. The computer chip 50 then increments thevalue of all of the DSFlags on the computer chip 50 to “1” (at aminimum, the DSFlags for the PIN and for the voiceprint, namelyDSFlag(001) and DSFlag(020), are incremented to “1”).

[0360] The digital signature, user information, and value of theidentification marker received by the card reader 3210 are thencommunicated to the computer 3202 for processing. If the computer 3202is a stand-alone computer, processing is performed within the computer3202 itself. More likely, however, computer 3202 will be networked andin communication with a server (not shown), which will actuallydetermine whether the suspect user 46 will gain access to the computer3202.

[0361] Assuming a server is involved, the server first confirms that theuser information received from the IC card 95 matches an authorized username or employee account number for access to and use of the specificcomputer 3202. The server then decrypts the digital signature using thepublic key associated with the matching user information. If thedecrypted hash value from the digital signature matches a hash valuecalculated based on the user information received from the IC card 95,as modified by the value of the identification marker received from theIC card 95, then the server determines that the IC card 95 from whichthe digital signature is received contains the unique private key.Finally, the server checks the verification status indicated by thevalue of the identification marker to determine whether the suspect user46 is in fact the authorized user of the IC card 95. This is a two-stepprocess since two different types of verification data have beenreceived by the IC card 95 and used to identify the verification statusof the card 95. In the first step, if the value of Rs is “01” (match),then the server infers that the suspect user 46 is the authorized user.In the second step, the server uses business logic or a rule base todetermine if the voiceprint provided by the suspect user 46 issufficiently similar to the voiceprint of the authorized user stored onthe IC card 95 so as to infer again that the suspect user 46 is theauthorized user.

[0362] The business logic and rule base of the server may be programmedto accept varying combinations of Rs and Rb values (PIN and voiceprint)to infer that the suspect user 46 is the authorized user. For example, acorrect PIN by itself, a correct PIN plus at least a 70% match ofvoiceprint, an incorrect PIN if the voiceprint exceeds 95%, and anincorrect PIN but two voiceprints exceeding 90% are all different typesof verification statuses that may be sufficient for the server to inferthat the suspect user 46 is the authorized user and grant access to thecomputer 3202. Obviously, the business logic or rule base can varywidely, depending upon the necessary security desired.

[0363] Turning now to FIG. 32b, the IC card 95 may also be used by thesuspect user 46 in accessing a secure website over an insecure network,such as the Internet 3222. In this further example, we will assume thatthe suspect user 46 is accessing the secure website 3224 of his broker3220, with whom he already has an established account. The brokeragecompany 3220 that operates the website 3224 already has the authorizeduser's public key from the IC card 95 stored in its account database3225 and associated with the authorized user's account. We will alsoassume that the suspect user 46 is accessing the website 3224 usingcomputer 3202 from FIG. 32a and that the card 95 has not been removedfrom the card reader 3210 since it was used to gain access to thecomputer 3202; thus, the DSFlags remain set to “1”.

[0364] When accessing the website 3224, the suspect user 46 enters auser ID in a login screen for the website. The user ID enables thebrokerage company 3220 readily to locate the appropriate account of theuser, as is conventional. However, rather than encrypting the user IDtogether with a password and then sending the encrypted information overthe Internet, the computer 3202 sends the user ID to the IC card 95 viathe card reader 3210. The process by which the website 3224 instructsthe computer 3202 to send the user ID to the IC card 95 rather thandirectly over the Internet to the website 3224 is beyond the scope ofthis invention; however, it may be readily accomplished in severaldifferent manners. In one example, the website 3224 has a dedicatedlogin page for use only by users having a suitable IC card 95 (or otherdevice of the present invention), in which case, entry of the user IDinto such login page automatically instructs the computer 3202 to sendthe user ID to the IC card 95 for processing. Alternatively, the loginpage for the website 3224 could enable the user to select a conventionallogin using an ID and password or to login using his IC card 95. Ineither of the above examples, the user ID could actually be prestored ina “cookie” in memory on the computer 3202, as is conventional, whichwould enable the user merely to click one button on the login page ofthe website 3224, which causes the computer 3202 to send the user ID tothe IC card 95.

[0365] Once a message input command comprising the user ID is receivedby the IC card 95, the computer chip 50 on the IC card 95 retrieves thecurrent value of the identification marker, modifies the user IDreceived from the card reader 3210 with the value of the identificationmarker by pre-pending the value to the user ID, calculates a hash valueof the modified user ID, encrypts the hash value to generate a digitalsignature, and returns the digital signature and the value of theidentification marker to the computer 3202 via the card reader 3210. Inthis case, the values of the DSFlags are not incremented since they arealready set to a value of “1.”

[0366] The user ID, the digital signature, and value of theidentification marker then are communicated in an EC by the computer3202 over the Internet 3222 to the website 3224 for processing. Computerprogramming associated with the website 3224 first confirms that thesuspect user 46 maintains an account with the brokerage company bymatching the user ID with an account. If an account with a matching userID is found, then the computer programming next decrypts the digitalsignature using the public key associated with the identified account.If the decrypted hash value from the digital signature matches a hashvalue calculated based on the user ID received from the IC card 95, asmodified by the value of the identification marker received from the ICcard 95, then it is determined that the IC card 95 from which thedigital signature is received contains the unique private keycorresponding with the account of the user. Finally, the computerprogramming associated with the website 3224 checks the verificationstatus indicated by the value of the identification marker to determinewhether the suspect user 46 is in fact the authorized user of the ICcard 95.

[0367] Preferably, the computer programming extracts only the value ofthe Rs from the value of the identification marker for initialevaluation. If the value of Rs is “00” (no PIN input), then the website3224 sends a request data back to the computer 3202 requesting input ofthe user's PIN. If the value of Rs is “10” (incorrect PIN), then thewebsite 3224 sends a request for the suspect user 46 to reenter the PIN.In either case, a suitable screen is displayed on the monitor 3206 ofthe computer 3202 to enable the suspect user 46 to enter the PIN. Itshould again be emphasized that such PIN will be transmitted by akeyboard of the computer 3202 to the card 95 but not transmitted overthe Internet 3222. If the value of Rs is “01” (correct PIN), then thewebsite 3224 infers that the suspect user 46 is in fact the authorizeduser and grants access to the website 3224. Thus, for mere access to thewebsite 3224, it is not necessary that the PIN be entered just prior tothe generation of the digital signature for the user ID—previous entryof a correct PIN is satisfactory for access to the website 3224.

[0368] On the other hand, if after perusing the website 3224, the“now-authorized” user requests a transaction, such as purchase of stock,then the website 3224 transmits a detailed confirmation of the requestedtransaction and specifically requests entry of a PIN to confirm specificapproval for the purchase order. Once the PIN has been input by thesuspect user 46, the computer 3202 provides the same to the IC card 95.

[0369] Upon receipt of the PIN, the controller 64 first retrieves theprestored data for the PIN from memory location data cell 001 in memorylocation 76 and compares it with the PIN received from the computer3202. A match/no-match determination then is made by the controller 64,and the value of Rs is set to either “01” representing a match or to“10” representing a failed match, and the DSFlag(001) also is set to“0”.

[0370] After a suitable but brief delay, the computer 3202 then sends amessage input command (which contains the purchase order) to the IC card95. The computer chip 50 on the IC card 95 retrieves the current valueof the identification marker (including therein the value of Rs andDSFlag(001)); modifies the message data received from the computer 3202with the value of the identification marker by pre-pending the value tothe message data; calculates a hash value of the modified message data;encrypts the hash value to generate a digital signature; and exports thedigital signature and value of the identification marker to the computer3202, which then forwards the same on to the website 3224. The computerchip 50 then increments the value of all of the DSFlags to “1.” In thisexample, the website 3224 will only approve the requested transactionwhen the value of the identification marker includes therein a value ofRs of “01” and a value of DSFlag(001) as “0”.

[0371] If desired, the communication between the computer 3202 and thewebsite 3224 may be performed using a Secure Socket Layering (SSL)protocol, as is conventional. Such a protocol is set forth, for example,in U.S. Pat. No. 5,848,161, which is incorporated herein by reference.In such protocol, it is customary for the computer 3202 to generate arandom number for use in creating a session key for the SSLcommunication. In accordance with a further feature of the presentinvention, the IC card 95 is used for the provision of the random numberfor creation of the session key. In particular, a digital signature isoriginated by the IC card 95 and used as the random number itself forthe purpose of creating the session key. An indirect result of the DSAand ECDSA specified in FIPS PUB 186-2 is that the resulting digitalsignature itself is a random number. A session key for communicationusing pretty good privacy (PGP) encryption also may be created based onthe digital signature of the IC card 95.

[0372] Turning now to FIG. 33, use of the IC card 95 at a point of salelocation is illustrated. A point of sale card reader 3308 includes analphanumeric keypad 3310, a display 3314, and, in this case, athumbprint reader 3312. The point of sale card reader 3308 is incommunication via data connector 3306 with a merchant cashregister/terminal 3302, which has its own display 3304. The point ofsale card reader 3308 is also in communication over an insecure network,such as the Internet 3322, with a banking authority 3320. The bankingauthority 3320 is either a financial institution that maintains abanking or credit card account on behalf of the authorized user of theIC card 95 or is an authorized approval agent or clearance authority forsuch a financial institution. In either case, the banking authority 3320maintains a database 3325, which associates the public key of the card95 with the corresponding account of the authorized user of the IC card95, and has the authority to approve or disapprove online transactionsrequested against such account.

[0373] When an item is purchased by the suspect user 46, the merchant“rings up” the item on the merchant cash register/terminal 3302 and thetotal balance due is displayed to the suspect user 46 on the display3304. To pay, the suspect user 46 inserts the IC card 95 into the pointof sale card reader 3308 (or brings the IC card 95 into proximity to thecard reader 3308). Upon insertion (or approach), the point of sale cardreader 3308 is initialized in a manner similar to the card readerspreviously described. The identification marker and all the DSFlags onthe computer chip 50 of the IC card 95 are reset when power is firstsupplied to the card 95 by the point of sale card reader 3308.

[0374] Next, the merchant cash register/terminal 3302 transmits thebalance due to the point of sale card reader 3308 via data connector3306. The point of sale card reader 3308 displays the balance due ondisplay 3314. In one embodiment, the display 3314 also prompts thesuspect user 46 to select whether he wants to pay using either a debitaccount or a credit card account. In an alternative embodiment, thepoint of sale card reader 3308 sends a “retrieve account information”command to the IC card 95, which returns a list of all availablechecking, credit card, or other accounts maintained in memory location80 on the computer chip 50 from which payment may be made. In thisalternative embodiment, the display 3314 prompts the suspect user 46 toselect one of the retrieved accounts for payment. The display 3314 nextprompts the suspect user 46 to enter a PIN using the alphanumeric keypad3310 and to place his right thumb on the thumbprint scanner 3312. Oncethe PIN and thumbprint have been input, the point of sale card reader3308 transmits both the PIN and a digitized version of the thumbprint tothe IC card 95. The card reader 3308 transmits the value of the PIN anddigitized thumbprint along with an identifier (e.g., 001 for the PIN and002 for the thumbprint) for each so that the card 95 “knows” the typeand order of the verification data input.

[0375] Upon receipt of the PIN and digitized version of the thumbprintby the IC card 95, the computer chip 50 on the card 95 identifies theverification status of the IC card 95 in the manner previouslydescribed. After a suitable but brief delay, the point of sale cardreader 3308 then sends a message input command to the IC card 95. Inthis case, the message input command includes message data comprising areceipt for the item purchased, the total balance due, and the paymentaccount specified by the suspect user 46. In the first embodiment, theaccount would be retrieved from memory location 80 (on the computer chip50) and inserted into the message data using a suitable “tag,”indicating whether the primary debit account or primary credit cardaccount number should be used. In the alternative embodiment, theaccount number for the account specifically selected by the suspect user46 from the list of available accounts displayed on display 3314 isincluded in the message data received from the card reader 3308.

[0376] Once the message input command is received by the IC card 95, thecomputer chip 50 on the IC card 95 retrieves the current value of theidentification marker (including therein the value of Rs andDSFlag(001), and including therein the values of Rb(002) andDSFlag(002)), modifies the message data received from the point of salecard reader 3308 with the value of the identification marker bypre-pending the value to the message data, calculates a hash value ofthe modified message data, encrypts the hash value to generate a digitalsignature, and exports the digital signature and value of theidentification marker to the point of sale card reader 3308. Thecomputer chip 50 then increments the value of all of the DSFlags to “1.”The digital signature, value of the identification marker, and messagedata (including account number and amount of the purchase) are thencommunicated by the point of sale card reader 3308 to banking authority3320 for processing.

[0377] The banking authority 3320 first confirms that the specifiedaccount number is a valid account number. The banking authority 3320then decrypts the digital signature using the public key associated withthe identified account number in the database 3325. If the decryptedhash value from the digital signature matches a hash value of themessage data, as modified by the value of the identification markerreceived from the IC card 95, then it is determined that the IC card 95from which the digital signature is received contains the unique privatekey and that the message data containing the receipt and total balancedue has not been modified since it was digitally signed.

[0378] Next, the banking authority 3320 checks the verification statusindicated by the value of the identification marker provided by the ICcard 95 to determine whether the suspect user 46 is in fact theauthorized user of the IC card 95. This is a two-step process as twodifferent types of verification data are received by the IC card 95 andused to identify the verification status of the IC card 95. In the firststep, if the value of Rs is “01”(match), then the banking authority 3320infers that the suspect user 46 is the authorized user. In the secondstep, the banking authority 3320 uses business logic or a rule base todetermine if the thumbprint provided by the suspect user 46 issufficiently similar to the thumbprint of the authorized user stored onthe card 95 so as to infer again that the suspect user 46 is theauthorized user.

[0379] The business logic and rule base of the banking authority 3320 issuch that it may rely upon varying combinations of values for Rs (PIN)and Rb(002) (thumbprint) in accepting the suspect user 46 as theauthorized user. For example, a correct PIN by itself, a correct PINplus at least a 60% match of thumbprint, an incorrect PIN if thethumbprint exceeds 96%, and an incorrect PIN but two thumbprintsexceeding 90% (but not identical) are all different types ofverification statuses that may be sufficient for the banking authority3320 to accept Factors B and C Entity Authentication of the suspect user46 by the card 95.

[0380] Finally, if the specified account has a sufficient balance orcredit to cover the requested purchase amount and there are no otherfactors (e.g. card reported stolen, duplicate request, etc.) that wouldwarrant refusal of the transaction, the banking authority 3320 grantsapproval of the transaction and transmit confirmation of the same backto the point of sale card reader 3308. Obviously, the business logic,rule base, and other factors that are taken into consideration by thebanking authority 3320 can vary widely, depending upon the necessarylevel of security desired by the banking authority 3320.

[0381] 5. Additional Security and Privacy Measures

[0382] a. Protecting Against Fraudulent Displays

[0383] A risk of using a device, such as the IC card 95, in conjunctionwith the example given in FIG. 33 is the fact that the user of the ICcard 95 must rely upon the display 3314 of the card reader 3308, whichis under the control of the point of sale merchant, to present an actualrepresentation of the message displayed for generating a digitalsignature with the IC card 95. It is possible for an unscrupulousmerchant, for example, to display a purchase price of one amount buthave the message data that is transmitted by the card reader 3308 to theIC card 95 to have a higher purchase price. To minimize the risk of suchfraud, it is preferable for the computer chip 50, described in FIG. 28,to be installed in a more sophisticated device, such as a PDA or cellphone, which has its own display (presumably under the control of theowner of the device). Since a PDA or cell phone could be programmed todisplay the full text of message data accurately prior to the generationof a digital signature thereof with the device, it would be moredifficult for a merchant to “present” one purchase price to the customerbut actually have a different purchase price included within the messageto be digitally signed.

[0384] b. Protecting Account Information

[0385] Unlike an IC card 95, a PDA or cell phone also provides the userwith much greater flexibility and privacy. For example, continuing withthe illustration from FIG. 33, rather than having the point of salereader 3308 prompt the user to select from only a limited number ofprimary payment accounts, a PDA or cell phone enables the user to storeand select from all payment accounts stored on the device. In addition,rather than having the point of sale reader 3308 actually retrieve allavailable payment accounts from the IC card 95, which potentially raisessome privacy concerns, a PDA or cell phone allows the user to select anaccount from a list presented by the device and not by the point of salemerchant. Thus, the point of sale merchant never becomes privy to thelist of account numbers maintained by the device.

[0386] c. Protecting Against Replay Attacks

[0387] In all of the examples illustrated in FIGS. 29-33, the partyreceiving the digital signature generated by the IC card 95 ispotentially subject to a replay attack. A replay attack occurs when anoriginal digital signature from a device is copied and then reused in anunauthorized manner. Since both the original and copy of a digitalsignature will decrypt with the appropriate public key, the partyreceiving the digital signature needs to have some way of distinguishingbetween the original and a later copy.

[0388] To prevent the acceptance of recorded digital signatures, it ismerely necessary for the party guarding against the replay attack toinclude a random number or unique message (e.g., time of day, date, andcounter combination) as part of each message input command sent to adevice for originating a digital signature and require that the randomnumber or unique message be included in what is digitally signed. Theparty receiving back the digital signature thereby is able to confirm,upon Message Authentication, that the digital signature received fromthe device was actually generated by the device in direct response tothe corresponding message input command. Such techniques are set forth,for example, in Federal Information Processing Standards Publication196, Entity Authentication Using Public Key Cryptography, US DOC/NBS,Feb. 18, 1997 (hereinafter “FIPS PUB 196”), which is incorporated hereinby reference and which is available for download athttp://csrc.nist.gov/publications/fips.

[0389] For applications in which the party receiving the digitalsignature (e.g., a card reader or associated controller) is involved inonly one authentication session at any given time and when a response isexpected substantially contemporaneously (e.g. while the device is in ornear a reader), it is only necessary to maintain the random number orunique message in computer memory long enough to ensure that the digitalsignature received back within the expected time interval contains theappropriate random number or unique message. This random number orunique message is good for only one digital signature and it is assumedthat the first digital signature received by the party is the originaland that subsequent identical digital signatures, if any, are fraudulentcopies and handled as such.

[0390] For applications in which the party receiving the digitalsignature is involved in more than one authentication session at anygiven time, such as, for example, a website that is entertainingsimultaneous requests from multiple users for entry to the site and/orfor transactions through the site, it is necessary for the party tomaintain a log of all random numbers or unique messages that have beensent out to all devices for the generation of digital signatures. It isalso necessary for the party to link or otherwise associate each suchrandom number or unique message with the particular session in which itis used. Thus, when a digital signature is received back within aparticular session, the party can confirm that the correct random numberwas received and digitally signed for such session

[0391] The generation of random numbers may be performed, for example,using any of the random number generators specified in appendix 3 ofFIPS PUB 186-2.

[0392] Accordingly, it readily will be understood by those personsskilled in the art that, in view of the above detailed description ofthe preferred embodiments, devices, and methods of the presentinvention, the present invention is susceptible of broad utility andapplication. Many methods, embodiments, and adaptations of the presentinvention other than those herein described, as well as many variations,modifications, and equivalent arrangements, will be apparent from orreasonably suggested by the present invention and the following detaileddescription thereof, without departing from the substance or scope ofthe present invention. Furthermore, those of ordinary skill in the artwill understand and appreciate that although steps of various processesmay be shown and described in some instances as being carried out in apreferred sequence or temporal order, the steps of such processes arenot necessarily to be limited to being carried out in such particularsequence or order. Rather, in many instances the steps of processesdescribed herein may be carried out in various different sequences andorders, while still falling within the scope of the present invention.Accordingly, while the present invention is described herein in detailin relation to preferred methods and devices, it is to be understoodthat this detailed description only is illustrative and exemplary of thepresent invention and is made merely for purposes of providing a fulland enabling disclosure of the invention. The detailed description setforth herein is not intended nor is to be construed to limit the presentinvention or otherwise to exclude any such other embodiments,adaptations, variations, modifications and equivalent arrangements ofthe present invention, the present invention being limited solely by theclaims appended hereto and the equivalents thereof.

What is claimed is:
 1. A method of providing a verification status of adevice, comprising the steps of: (a) identifying within a device acurrent verification status out of a plurality of predefinedverification statuses of the device as a function of verification datainput into the device and data prestored within the device, one of thepredefined verification statuses being representative of theverification data being the same as the prestored data, and at least oneother verification status being representative of the verification databeing different from the prestored data; and (b) independent of theverification status identified, transmitting said identifiedverification status to an electronic apparatus external to the device.2. The method of claim 1, further comprising outputting from the devicean indicator of said identified verification status.
 3. A method ofproviding a verification status regarding an entity authentication,comprising the steps of: (a) receiving within a device input comprisingverification data of an entity; (b) identifying within the device acurrent verification status out of a plurality of predefinedverification statuses of the device as a function of the verificationdata and data prestored within the device, one of the predefinedverification statuses being representative of the verification databeing the same as the prestored data, and at least one otherverification status being representative of the verification data beingdifferent from the prestored data; and (c) independent of theverification status identified, outputting from the device an indicatorof said identified verification status.
 4. A method of authenticating afirst entity to a second entity, comprising the steps of: (a) within averification component of a device, (i) storing data of the first entityduring a personalization of the verification component, (ii) laterreceiving verification data input within the device, and (iii)identifying as a function of the verification data and prestored data acurrent verification status out of a plurality of predefinedverification statuses of the device, including one verification statusrepresentative of the verification data being the same as the prestoreddata, and at least one other verification status representative of theverification data being different from the prestored data; and (b)independent of the verification status identified, communicating saididentified verification status to the second entity.
 5. The method ofclaim 4, wherein said step of communicating said identified verificationstatus to the second entity comprises the steps of outputting from theverification component an indicator of said identified verificationstatus and transmitting said output indicator to the second entity.
 6. Amethod of providing a verification status regarding an entityauthentication, comprising the steps of: (a) maintaining within a deviceprestored data of an entity for identifying a verification status of thedevice as a function of the prestored data and verification data laterinput into the device; (b) identifying within the device a currentverification status of the device representing the lack of input of anyverification data during a predefined period of time; and (c) outputtingfrom the device an indicator of said identified verification status forevaluation thereof.
 7. The method of claim 6, further comprising thesteps of, (a) receiving within the device input comprising verificationdata; (b) identifying within the device a current verification statusout of a plurality of predefined verification statuses of the device bycomparing said received verification data with the prestored data; and(c) again outputting from the device an indicator of said identifiedverification status for evaluation thereof, the second indicatorrevealing said identified verification status based on said comparison.8. The method of claim 7, wherein one verification status out of theplurality of predefined verification statuses of the device isrepresentative of the verification data being the same as the prestoreddata, and at least one other predefined verification status isrepresentative of the verification data being different from theprestored data.
 9. The method of claim 2, 3, 5, or 7, further comprisingthe steps of generating a digital signature for the indicator andoutputting the digital signature from the device.
 10. The method ofclaims 2, 3, 5, or 6, wherein the prestored data comprises a Secret. 11.The method of claims 2, 3, 5, or 6, wherein the prestored data comprisesbiometric data.
 12. The method of claims 1, 3, 4, or 7, wherein theverification status identified as the current verification statusrepresents a relational correspondence between the verification data andthe prestored data without revealing either of the verification data orthe prestored data.
 13. The method of claims 1, 3, 4, or 6, wherein theprestored data comprises biometric data.
 14. The method of claims 1, 3,4, or 6, wherein the device prestores data for a plurality of users ofthe device.
 15. The method of claim 1, wherein said step of identifyingincludes assigning an identification marker within the device equal to avalue out of a set of predefined values corresponding to said predefinedverification statuses.
 16. The method of claim 3, wherein said step ofidentifying includes assigning an identification marker within thedevice equal to a value out of a set of predefined values correspondingto said predefined verification statuses.
 17. The method of claim 4,wherein said step of identifying includes assigning an identificationmarker within the device equal to a value out of a set of predefinedvalues corresponding to said predefined verification statuses.
 18. Themethod of claim 7, wherein said step of identifying includes assigningan identification marker within the device equal to a value out of a setof predefined values corresponding to said predefined verificationstatuses.
 19. The method of claims 15, 16, 17, or 18, further comprisingthe steps of generating a digital signature within the device andoutputting the digital signature and the value of the identificationmarker from the device.
 20. The method of claim 19, wherein the digitalsignature is generated based on the value of the identification marker.21. The method of claim 19, wherein the digital signature is output fromthe device separately from the value of the identification marker. 22.The method of claims 15, 16, 17, or 18, wherein said prestored datacomprises biometric data, wherein the identification marker is assigneda value representing the type of biometric data.
 23. The method of claim1, further comprising evaluating with business logic incorporated withinthe electronic apparatus a request based on said identified verificationstatus.
 24. The method of claim 3, further comprising receiving andevaluating a request based on said output indicator.
 25. The method ofclaim 4, further comprising receiving and evaluating a request based onsaid communicated verification status.
 26. The method of claim 6,further comprising receiving and evaluating a request based on saidoutput indicator.
 27. The method of claim 7, further comprisingreceiving and evaluating a request based on said output indicator.
 28. Amethod of providing a verification status of a device, comprising thesteps of: (a) identifying within a device a current verification statusout of a plurality of verification statuses of the device as a functionof biometric verification data input into the device and biometric dataprestored within the device; and (b) independent of the verificationstatus identified, transmitting an indicator of said identifiedverification status to an electronic apparatus external to the device,the indicator revealing said identified verification status withoutrevealing either of the verification data or the prestored data.
 29. Themethod of claim 28, further comprising outputting from the device theindicator of said identified verification status.
 30. A method ofproviding a verification status regarding an entity authentication,comprising the steps of: (a) receiving within a device input comprisingbiometric verification data of an entity; (b) identifying within thedevice a current verification status out of a plurality of verificationstatuses of the device as a function of the verification data andbiometric data prestored within the device; and (c) independent of theverification status identified, outputting from the device an indicatorof said identified verification status, the indicator revealing saididentified verification status without revealing either of theverification data or the prestored data.
 31. A method of authenticatinga first entity to a second entity, comprising the steps of: (a) within averification component of a device, (i) storing biometric data of thefirst entity during a personalization of the verification component,(ii) later receiving biometric verification data input within thedevice, and (iii) identifying as a function of the verification data andthe prestored data a current verification status out of a plurality ofverification statuses of the device; and (b) independent of theverification status identified, communicating said identifiedverification status to the second entity by outputting from theverification component an indicator of said identified verificationstatus and transmitting said output indicator to the second entity, theindicator revealing said identified verification status withoutrevealing either of the verification data or the prestored data.
 32. Amethod of providing a verification status regarding an entityauthentication, comprising the steps of: (a) maintaining within a deviceprestored biometric data of an entity for identifying a verificationstatus of the device as a function of the prestored data and biometricverification data later input into the device; (b) identifying withinthe device a current verification status of the device representing thelack of input of any verification data during a predefined period oftime; (c) outputting from the device an indicator of said identifiedverification status for evaluation thereof; (d) receiving within thedevice input comprising verification data; (e) identifying within thedevice a current verification status out of a plurality of predefinedverification statuses of the device by comparing said receivedverification data with the prestored data; and (f) again outputting fromthe device an indicator of said identified verification status forevaluation thereof, the second indicator revealing said identifiedverification status based on said comparison but neither revealing theverification data nor the prestored data.
 33. The method of claims 28,30, 31, or 32, wherein one verification status out of the plurality ofpredefined verification statuses of the device is representative of theverification data being the same as the prestored data, and at least oneother predefined verification status is representative of theverification data being different from the prestored data.
 34. Themethod of claim 28, wherein said step of identifying includes assigningan identification marker within the device equal to a value out of a setof predefined values corresponding to the predefined verificationstatuses.
 35. The method of claim 30, wherein said step of identifyingincluding assigning an identification marker within the device equal toa value out of a set of predefined values corresponding to thepredefined verification statuses.
 36. The method of claim 31, whereinsaid step of identifying including assigning an identification markerwithin the device equal to a value out of a set of predefined valuescorresponding to the predefined verification statuses.
 37. The method ofclaim 32, wherein said step of identifying including assigning anidentification marker within the device equal to a value out of a set ofpredefined values corresponding to the predefined verification statuses.38. The method of claims 34, 35, 36, or 37, wherein the identificationmarker is assigned a value representing the type of biometric data. 39.The method of claims 35 or 37, wherein the identification marker isassigned a value equated with a successful verification, and wherein theindicator comprises said assigned value of the identification marker.40. The method of claim 39, wherein the device generates digitalsignatures.
 41. The method of claim 40, wherein said assigned valuefurther represents whether a digital signature was generated by thedevice since verification data was last input into the device.
 42. Themethod of claim 28, further comprising evaluating with business logicincorporated within the electronic apparatus a request based on saididentified verification status.
 43. The method of claim 30, furthercomprising receiving and evaluating a request based on said outputindicator.
 44. The method of claim 31, further comprising receiving andevaluating a request based on said communicated verification status. 45.The method of claim 32, further comprising receiving and evaluating arequest based on said output indicator.
 46. A method of providing averification status of a device, comprising the steps of: (a)identifying within a device that generates a digital signature a currentverification status out of a plurality of predefined verificationstatuses of the device; (b) generating within the device a digitalsignature for a message as a function of said identified verificationstatus, including modifying within the device data representing themessage as a function of said identified verification status of thedevice, said generated digital signature comprising an indicator of saididentified verification status; and (c) transmitting said generateddigital signature to an electronic apparatus external to the device. 47.The method of claim 46, wherein said step of identifying the currentverification status is a function of verification data input into thedevice and data prestored within the device.
 48. A method of providing averification status regarding an entity authentication, comprising thesteps of: (a) receiving within a device that generates a digitalsignature input comprising verification data of an entity; (b)identifying within the device a current verification status out of aplurality of predefined verification statuses of the device as afunction of the verification data and data prestored within the device;(c) generating within the device a digital signature for a message as afunction of said identified verification status, including modifyingwithin the device data representing the message as a function of saididentified verification status of the device, said generated digitalsignature comprising an indicator of said identified verificationstatus; and (d) outputting from the device said generated digitalsignature.
 49. A method of authenticating a first entity to a secondentity, comprising the steps of: (a) within a verification component ofa device that generates a digital signature, (i) storing data of thefirst entity during a personalization of the verification component,(ii) later receiving verification data input within the device, (iii)identifying a current verification out of a plurality of predefinedverification statuses of the device as a function of the verificationdata and prestored data within the device, (iv) generating within thedevice a digital signature for a message as a function of saididentified verification status, including modifying within the devicedata representing the message as a function of said identifiedverification status of the device, said generated digital signaturecomprising an indicator of said identified verification status, and (v)outputting from the verification component said generated digitalsignature; and (b) communicating said identified verification status tothe second entity by transmitting said generated digital signature tothe second entity.
 50. A method of providing a verification statusregarding an entity authentication, comprising the steps of: (a)maintaining within a device prestored data of an entity for identifyinga verification status of the device as a function of the prestored dataand verification data later input into the device; (b) identifyingwithin the device a current verification status of the devicerepresenting the lack of input of any verification data during a periodof time; (c) generating within the device a digital signature for amessage using a private key of a public-private key pair, said generateddigital signature comprising an indicator of said identifiedverification status; and (d) outputting from the device said generateddigital signature for evaluation thereof.
 51. The method of claim 50,further comprising the steps of, (a) receiving within the device inputcomprising verification data; (b) identifying within the device acurrent verification status out of a plurality of predefinedverification statuses of the device as a function of said receivedverification data and the prestored data; (c) generating within thedevice another digital signature for a message as a function of saididentified verification status, including modifying within the devicedata representing the message as a function of said identifiedverification status of the device, said second generated digitalsignature comprising an indicator of said identified verificationstatus; and (d) outputting from the device said second generated digitalsignature for evaluation thereof.
 52. The method of claims 46, 48, 49,or 51, wherein said step of generating the digital signature furtherincludes encrypting within the device said modified data using a privatekey of a public-private key pair.
 53. The method of claims 46, 48, 49,or 51, wherein said step of generating the digital signature includesencrypting within the device using a private key of a public-private keypair a message digest calculated within the device for said modifieddata.
 54. The method of claims 46, 48, 49, and 51, further comprisingoutputting from the device the digital signature for said modified data,but not outputting said modified data.
 55. The method of claim claims46, 48, 49, or 50, wherein the data representing the message comprises ahash value of the message.
 56. The method of claims 46, 48, 49, or 50,wherein the data representing the message comprises a message digest forthe message.
 57. The method of claims 46, 48, 49, or 50, wherein thedata representing the message is stored within the device.
 58. Themethod of claims 46, 48, 49, or 50, wherein the message is composedwithin the device by a user of the device.
 59. The method of claims 46,48, 49, or 50, wherein a portion of the message is composed within anI/O support element external to the device which, in turn, transmitsinput representing the portion of the message into the device through aninterface of the device.
 60. The method of claim 59, wherein a remainingportion of the message is composed within the device.
 61. The method ofclaims 46, 48, 49, or 50, wherein the message is composed within an I/Osupport element external to the device which, in turn, transmits theinput representing the message into the device through an interface ofthe device.
 62. The method of claim 61, wherein the I/O support elementcomprises a point of sale terminal.
 63. The method of claim 61, whereinthe I/O support element comprises a biometric scanner.
 64. The method ofclaim 61, wherein the I/O support element comprises a card reader. 65.The method of claim 61, wherein the I/O support element comprises acomputer.
 66. The method of claim 61, further comprising the step ofdisplaying the message on a display screen of the device for review andapproval by a user.
 67. The method of claims 46, 48, 49, or 51, furthercomprising the step of requiring verification data to be input into thedevice following a predefined period of time after a last successfulverification.
 68. The method of claims 46, 48, 49, or 51, furthercomprising the step of requiring verification data to be input into thedevice for each one of a particular type of message.
 69. The method ofclaim 68, wherein the particular type of message is a request for afinancial transaction.
 70. The method of claim 68, further comprisingnot requiring verification data to be input into the device for othertypes of messages.
 71. The method of claims 46, 48, 49, or 51, furthercomprising not requiring verification data to be input into the devicefor a predefined period of time.
 72. The method of claim 71, wherein thepredefined period of time comprises the time between approval of arequest embodied in a message and a powering off of the device.
 73. Themethod of claims 46, 48, 49, or 51, further comprising the step ofauthenticating the message using said generated digital signature,including the steps of, (a) modifying data representing the messageembodying the request as a function of a suspected verification statusof the device, (b) calculating a message digest as a function of saidmodified data, (c) decrypting said generated digital signature using thepublic key of the public-private key pair, and (d) concluding theverification status of the device as being the suspected verificationstatus of the device when said calculated message digest matches saiddecrypted digital signature.
 74. The method of claims 47, 48, 49, or 51,wherein one verification status out of the plurality of predefinedverification statuses of the device is representative of theverification data being the same as the prestored data, and at least oneother predefined verification status is representative of theverification data being different from the prestored data.
 75. Themethod of claims 47, 48, 49, or 51, wherein the indicator of saididentified verification status neither reveals the prestored data northe verification data.
 76. The method of claims 46, 48, 49, or 50,wherein the message is for the performance of a financial transaction.77. The method of claims 46, 48, 49, or 50, wherein the message is forthe performance of a legal action.
 78. The method of claims 46, 48, 49,or 50, wherein the message is predetermined and static.
 79. The methodof claims 46, 48, 49, or 50, wherein the message is prestored within thedevice.
 80. The method of claims 46, 48, 49, or 50, wherein the messageis the verification data.
 81. The method of claims 46, 48, 49, or 50,wherein the message is a request for access to a physical space.
 82. Themethod of claims 46, 48, 49, or 50, wherein the message is a request foraccess to a web site.
 83. The method of claims 46, 48, 49, or 50,wherein the message is a request for access to a database.
 84. Themethod of claims 46, 48, 49, or 50, wherein the message is a request foraccess to a computer program.
 85. The method of claim 46, wherein saidstep of identifying includes assigning an identification marker withinthe device equal to a value out of a set of predefined valuescorresponding to said predefined verification statuses.
 86. The methodof claim 85, wherein said step of identifying the current verificationstatus is a function of verification data input into the device and dataprestored within the device.
 87. The method of claim 48, wherein saidstep of identifying includes assigning an identification marker withinthe device equal to a value out of a set of predefined valuescorresponding to said predefined verification statuses.
 88. The methodof claim 49, wherein said step of identifying includes assigning anidentification marker within the device equal to a value out of a set ofpredefined values corresponding to said predefined verificationstatuses.
 89. The method of claim 51, wherein said step of identifyingincludes assigning an identification marker within the device equal to avalue out of a set of predefined values corresponding to said predefinedverification statuses.
 90. The method of claims 85, 87, 88, or 89,wherein said step of generating the digital signature includesencrypting within the device using a private key of a public-private keypair a message digest calculated within the device for said modifieddata.
 91. The method of claims 86, 87, or 88, wherein said step ofidentifying the current verification status as a function of theverification data and the prestored data includes comparing theverification data with the prestored data.
 92. The method of claims 86,87, 88, or 89, wherein one verification status out of the plurality ofpredefined verification statuses of the device is representative of theverification data being the same as the prestored data, and at least oneother predefined verification status is representative of theverification data being different from the prestored data.
 93. Themethod of claims 86, 87, 88, or 89, wherein the prestored data comprisesa Secret.
 94. The method of claims 86, 87, 88, or 89, wherein theprestored data and verification data comprises biometric data.
 95. Themethod of claim 94, wherein the identification marker is assigned avalue representing the type of biometric data.
 96. The method of claims85, 87, 88, or 89, wherein said step of modifying comprises embeddingsaid assigned value of the identification marker within the datarepresenting the message.
 97. The method of claims 85, 87, 88, or 89,wherein said step of modifying comprises appending said assigned valueof the identification marker to the data representing the message. 98.The method of claim 97, wherein said step of modifying comprisesappending said assigned value of the identification marker to thebeginning of the data representing the message.
 99. The method of claim97, wherein said step of modifying comprises appending said assignedvalue of the identification marker to the end of the data representingthe message.
 100. The method of claims 86, 87, 88, or 89, wherein theidentification marker is assigned a value equated with a successfulverification, and wherein said assigned value further represents whethera digital signature was generated since verification data was last inputinto the device.
 101. The method of claim 100, wherein said generateddigital signature comprises the indicator.
 102. The method of claim 46,further comprising evaluating with business logic incorporated withinthe electronic apparatus a request based on said generated digitalsignature.
 103. The method of claim 102, wherein said step ofidentifying the current verification status is a function ofverification data input into the device and data prestored within thedevice.
 104. The method of claim 48, further comprising receiving andevaluating a request based on said generated digital signature.
 105. Themethod of claim 49, further comprising receiving and evaluating therequest based on said generated digital signature.
 106. The method ofclaim 51, further comprising receiving and evaluating the request basedon said generated digital signature.
 107. The method of claim 106,further comprising the steps of, (a) receiving within the device inputcomprising verification data; (b) identifying within the device acurrent verification status out of a plurality of predefinedverification statuses of the device as a function of said receivedverification data and the prestored data; (c) generating within thedevice another digital signature for a message as a function of saididentified verification status, including modifying within the devicedata representing the message as a function of said identifiedverification status of the device, said second generated digitalsignature comprising an indicator of said identified verificationstatus; (d) outputting from the device said second generated digitalsignature; and (e) evaluating the request based on said second generateddigital signature.
 108. The method of claims 102, 104, 105, or 107,wherein said step of generating the digital signature further includesencrypting within the device said modified data using a private key of apublic-private key pair.
 109. The method of claims 102, 104, 105, or107, wherein said step of generating the digital signature includesencrypting within the device using a private key of a public-private keypair a message digest calculated within the device for said modifieddata.
 110. The method of claim 109, wherein the verification statusidentified as the current verification status represents a relationalcorrespondence between the verification data and the prestored datawithout revealing either of the verification data or the prestored data.111. The method of claims 102, 104, 105, or 106, wherein the prestoreddata comprises a Secret.
 112. The method of claims 102, 104, 105, or106, wherein the prestored data comprises biometric data.
 113. A methodof providing a verification status of a device, comprising the steps of:(a) identifying within a device that generates a digital signature averification status out of a plurality of verification statuses of thedevice as a function of prestored data and verification data later inputinto the device, including, (i) comparing verification data representinga Secret with the data prestored within the device and assigning, basedon said comparison, a first comparison marker within the device equal toa value out of a set of predefined values, and (ii) comparingverification data representing biometric data with the data prestoredwithin the device and assigning, based on said comparison, a secondcomparison marker within the device equal to a value out of a set ofpredefined values; (b) generating within the device a digital signaturefor a message, including modifying within the device data representingthe message as a function of said assigned values for the first andsecond comparison markers, said generated digital signature comprisingan indicator of said identified verification status; and (c)transmitting said generated digital signature to an electronic apparatusexternal to the device.
 114. A method of providing a verification statusregarding an entity authentication, comprising the steps of: (a)receiving within a device that generates a digital signature inputcomprising verification data of an entity, the verification datarepresenting both a Secret and biometric data; (b) identifying withinthe device a verification status out of a plurality of verificationstatuses of the device as a function of data prestored within the deviceand the, including, (i) comparing verification data representing theSecret with the data prestored within the device and assigning, based onsaid comparison, a first comparison marker within the device equal to avalue out of a set of predefined values, and (ii) comparing verificationdata representing biometric data with the data prestored within thedevice and assigning, based on said comparison, a second comparisonmarker within the device equal to a value out of a set of predefinedvalues; (c) generating within the device a digital signature for amessage, including modifying within the device data representing themessage as a function of said assigned values for the first and secondcomparison markers, said generated digital signature comprising anindicator of said identified verification status; and (d) outputtingfrom the device said generated digital signature.
 115. A method ofauthenticating a first entity to a second entity, comprising the stepsof: (a) within a verification component of a device that originates adigital signature, (i) storing data of the first entity during apersonalization of the verification component, the prestored datarepresenting both a Secret and biometric data of the first entity; (ii)later receiving verification data input within the device; (iii)identifying a current verification status out of a plurality ofverification statuses of the device as a function of the prestored dataand verification data, including, (A) comparing verification datarepresenting the Secret with data prestored within the device andassigning, based on said comparison, a first comparison marker withinthe device equal to a value out of a set of predefined values, and (B)comparing verification data representing biometric data with dataprestored within the device and assigning, based on said comparison, asecond comparison marker within the device equal to a value out of a setof predefined values; (iv) generating within the device a digitalsignature for a message, including modifying within the device datarepresenting the message as a function of said assigned values for thefirst and second comparison markers, said generated digital signaturecomprising an indicator of said identified verification status; and (v)outputting from the verification component said generated digitalsignature; and (b) communicating said identified verification status tothe second entity by transmitting said generated digital signature tothe second entity.
 116. A method of providing a verification status of adevice, comprising the steps of: (a) identifying within a device thatgenerates a digital signature a verification status out of a pluralityof verification statuses of the device as a function of prestored dataand verification data later input into the device, including, (i)comparing verification data representing a Secret with the dataprestored within the device and assigning, based on said comparison, afirst comparison marker within the device equal to a value out of a setof predefined values, and (ii) comparing verification data representingbiometric data with the data prestored within the device and assigning,based on said comparison, a second comparison marker within the deviceequal to a value out of a set of predefined values; (b) generatingwithin the device a digital signature for a message, including modifyingwithin the device data representing the message as a function of onlyone of said assigned values for the first and second comparison markers,said generated digital signature comprising an indicator of saididentified verification status; and (c) transmitting to an electronicapparatus external to the device said generated digital signature andthe other of said assigned values for the first and second comparisonmarkers.
 117. A method of providing a verification status regarding anentity authentication, comprising the steps of: (a) receiving within adevice that generates a digital signature input comprising verificationdata of an entity, the verification data representing both a Secret andbiometric data; (b) identifying within the device a verification statusout of a plurality of verification statuses of the device as a functionof data prestored within the device and verification data later inputinto the device, including, (i) comparing verification data representingthe Secret with the data prestored within the device and assigning,based on said comparison, a first comparison marker within the deviceequal to a value out of a set of predefined values, and (ii) comparingverification data representing biometric data with the data prestoredwithin the device and assigning, based on said comparison, a secondcomparison marker within the device equal to a value out of a set ofpredefined values; (c) modifying within the device data representing amessage as a function of only one of said assigned values for the firstand second comparison markers; (d) generating within the device adigital signature for the message by encrypting said modified data suchthat said generated digital signature comprises an indicator of saididentified verification status; and (e) outputting from the device saidgenerated digital signature and the other of said assigned values forthe first and second comparison markers.
 118. A method of authenticatinga first entity to a second entity, comprising the steps of: (a) within averification component of a device that originates a digital signature,(i) storing data of the first entity during a personalization of theverification component, the prestored data representing both a Secretand biometric data of the first entity; (ii) later receivingverification data input within the device; (iii) identifying a currentverification status out of a plurality of verification statuses of thedevice as a function of the prestored data and verification data,including, (A) comparing verification data representing the Secret withdata prestored within the device and assigning, based on saidcomparison, a first comparison marker within the device equal to a valueout of a set of predefined values, and (B) comparing verification datarepresenting biometric data with data prestored within the device andassigning, based on said comparison, a second comparison marker withinthe device equal to a value out of a set of predefined values; (iv)modifying within the device data representing a message as a function ofonly one of said assigned values for the first and second comparisonmarkers; (v) generating within the device a digital signature for themessage by encrypting said modified data such that said generateddigital signature comprises an indicator of said identified verificationstatus; and (vi) outputting from the verification component saidgenerated digital signature and the other of said assigned values forthe first and second comparison markers; and (b) communicating saididentified verification status to the second entity by transmitting saidgenerated digital signature to the second entity.
 119. The method ofclaims 113, 114, 115, 116, 117, or 118, wherein said step of generatingthe digital signature further includes encrypting within the device saidmodified data using a private key of a public-private key pair.
 120. Themethod of claims 113, 114, 115, 116, 117, or 118, wherein said step ofgenerating the digital signature includes encrypting within the deviceusing a private key of a public-private key pair a message digestcalculated within the device for said modified data.
 121. The method ofclaims 113, 114, 115, 116, 117, or 118, wherein the first comparisonmarker is assigned a value equated with a successful verification whensaid comparison results in a match, including an exact match.
 122. Themethod of claim 121, wherein said assigned value further representswhether a digital signature was generated since verification datarepresenting the Secret was last input into the device.
 123. The methodof claim 121, wherein the first comparison marker is assigned a valuerepresenting whether any verification data representing the Secret wasinput into the device within a predefined time period.
 124. The methodof claim 123, wherein the predefined period of time comprises the timesince the last successful verification.
 125. The method of claim 123,wherein the predefined period of time comprises the time since aresetting of the device.
 126. The method of claims 113, 114, 115, 116,117, or 118, wherein the second comparison marker is assigned a valueequated with a successful verification when said comparison results in amatch, but not an exact match.
 127. The method of claim 126, whereinsaid assigned value further represents whether a digital signature wasgenerated subsequent to said comparison resulting in a match.
 128. Themethod of claims 113, 114, 115, 116, 117, or 118, wherein the firstcomparison marker is assigned a value representing a differencedetermined from said comparison between the verification datarepresenting the Secret and the prestored data.
 129. The method ofclaims 113, 114, 115, 116, 117, or 118, wherein the second comparisonmarker is assigned a value representing a degree of match between theverification data representing the biometric data and the prestoreddata.
 130. The method of claim 129, wherein the value is equated with apercentage of match between the verification data representing thebiometric data and the prestored data.
 131. The method of claim 129,wherein the second comparison marker is assigned a value furtherrepresenting the type of biometric data input into the device.
 132. Themethod of claims 113, 114, 115, 116, 117, or 118, wherein the secondcomparison marker is assigned a value equated with an unsuccessfulverification when said comparison results in an exact match.
 133. Themethod of claims 113, 114, 115, 116, 117, or 118, wherein the secondcomparison marker is assigned a value equated with a successfulverification when said comparison results in a proximate match.
 134. Themethod of claim 133, wherein said assigned value further representswhether a digital signature was generated subsequent to said comparisonresulting in a proximate match.
 135. The method of claim 133, whereinsaid assigned value further represents whether a digital signature wasgenerated since verification data representing the biometric data waslast input into the device.
 136. The method of claim 133, wherein saidassigned value further represents whether any verification datarepresenting the biometric data was input into the device within apredetermined time period.
 137. The method of claim 136, wherein thepredefined period of time comprises the time since the last successfulverification.
 138. The method of claim 136, wherein the predefinedperiod of time comprises the time since a resetting of the device. 139.The method of claims 113, 114, 115, 116, 117, or 118, further comprisingthe step of outputting said assigned value of the first comparisonmarker.
 140. The method of claims 113, 114, 115, 116, 117, or 118,further comprising the step of outputting said assigned value of thesecond comparison marker.
 141. The method of claims 113, 114, 115, 116,117, or 118, further comprising the step of outputting said assignedvalue of the first and second comparison markers.
 142. The method ofclaims 113, 114, 115, 116, 117, or 118, wherein said step of modifyingcomprises embedding said assigned value of the first comparison markerwithin the data representing the message.
 143. The method of claims 113,114, 115, 116, 117, or 118, wherein said step of modifying comprisesappending said assigned value of the first comparison marker to the datarepresenting the message.
 144. The method of claim 143, wherein saidstep of modifying comprises appending said assigned value of the firstcomparison marker to the beginning of the data representing the message.145. The method of claim 143, wherein said step of modifying comprisesappending said assigned value of the first comparison marker to the endof the data representing the message.
 146. The method of claims 113,114, 115, 116, 117, or 118, wherein said step of modifying comprisesembedding said assigned value of the second comparison marker within thedata representing the message.
 147. The method of claims 113, 114, 115,116, 117, or 118, wherein said step of modifying comprises appendingsaid assigned value of the second comparison marker to the datarepresenting the message.
 148. The method of claim 147, wherein saidstep of modifying comprises appending said assigned value of the secondcomparison marker to the beginning of the data representing the message.149. The method of claim 147, wherein said step of modifying comprisesappending said assigned value of the second comparison marker to the endof the data representing the message.
 150. The method of claims 113,114, or 115, wherein said step of modifying comprises embedding saidassigned value of the first and second comparison markers within thedata representing the message.
 151. The method of claims 113, 114, or115, wherein said step of modifying comprises appending said assignedvalue of the first and second comparison markers to the datarepresenting the message.
 152. The method of claim 151, wherein saidstep of modifying comprises appending said assigned value of the firstand second comparison markers to the beginning of the data representingthe message.
 153. The method of claim 151, wherein said step ofmodifying comprises appending said assigned value of the first andsecond comparison markers to the end of the data representing themessage.
 154. The method of claims 6, 32, 51, 89, or 107, wherein thepredefined period of time comprises the time since a last successfulverification.
 155. The method of claims 6, 32, 51, 89, or 107, whereinthe predefined period of time comprises a fixed time interval followinga successful verification.
 156. The method of claims 6, 32, 51, 89, or107, wherein the predefined period of time comprises the time since aresetting of the device.
 157. The method of claims 1, 3, 4, 28, 30, 31,47, 48, 49, 103, 104, or 105, wherein said step of identifying thecurrent verification status as a function of the verification data andthe prestored data includes comparing the verification data with theprestored data.
 158. The method of claims 2, 3, 5, 7, 28, 30, or 31,further comprising the steps of generating a digital signature withinthe device and outputting the digital signature from the device. 159.The method of claim 158, wherein said generated digital signaturecomprises the indicator.
 160. The method of claims 2,3,5,7, 28, 30, 31,or 32, further comprising the steps of, (a) modifying within the devicedata representing a message as a function of said identifiedverification status of the device, (b) calculating within the device amessage digest for said modified data, and (c) encrypting within thedevice said calculated message digest using a private key of apublic-private key pair to generate a digital signature for the message,said generated digital signature comprising the indicator of saididentified verification status.
 161. The method of claim 160, whereinthe device generates a digital signature in response to an externalinquiry received by the device.
 162. The method of claim 160, whereinthe device generates a digital signature in response to receipt of datarepresenting the message.
 163. The method of claim 160, wherein thedevice generates a digital signature in response to receipt of inputcomprising the verification data.
 164. The method of claims 2, 3, 5, 6,28, 30, 31, 32, 47, 48, 49, 51, 85, 87, 88, 89, 104, 105, 106, or 107,wherein the indicator points definitively to a single verificationstatus of the device.
 165. The method of claim 2, 3, 5, 6, 28, 30, 31,32, 47, 48, 49, 51, 86; 87, 88, or 89, wherein the indicator revealssaid identified verification status without revealing either of theverification data or the prestored data.
 166. The method of claims 1,3,4, 7, 28, 30, 31, 32, 47, 48, 49, or 51, wherein verification datainput into the device is not exportable from the device.
 167. The methodof claims 1, 3, 4, 7, 28, 30, 31, 32, 47, 48, 49, or 51, furthercomprising receiving the verification data within an I/O support elementexternal to the device and transmitting the input comprising theverification data from the I/O support element into the device.
 168. Themethod of claim 167, wherein the I/O support element comprises a pointof sale terminal.
 169. The method of claim 167, wherein the I/O supportelement comprises a biometric scanner.
 170. The method of claim 167,wherein the I/O support element comprises a card reader.
 171. The methodof claim 167, wherein the I/O support element comprises a computer. 172.The method of claims 1, 3, 4, 6, 28, 30, 31, 32, 47, 48, 49, or 50,wherein the prestored data is not exportable from the device.
 173. Themethod of claim 172, wherein the prestored data represents a digitizedfingerprint.
 174. The method of claim 172, wherein the prestored datarepresents a digitized handprint or hand geometry.
 175. The method ofclaim 172, wherein the prestored data represents a digitized retina.176. The method of claim 172, wherein the prestored data represents adigitized iris.
 177. The method of claim 172, wherein the prestored datarepresents a digitized voice print.
 178. The method of claim 172,wherein the prestored data represents a digitized facial scan.
 179. Themethod of claim 172, wherein the prestored data represents a digitizedwritten signature.
 180. The method of claim 172, wherein the prestoreddata represents a digitized DNA sample.
 181. The method of claim 172,wherein the device includes a biometric scanner for inputting of theverification data.
 182. The method of claim 172, wherein the deviceprestores data for a plurality of different types of biometric data.183. The method of claim 182, wherein the different types of thebiometric data are for a single user of the device.
 184. The method ofclaim 182, wherein the different types of the biometric data arerespectively for different users of the device.
 185. The method ofclaims 1, 3, 4, 6, 28, 30, 31, 32, 47, 48, 49, or 50, wherein theprestored data are for an authorized user of the device.
 186. The methodof claim 185, wherein the device is a personal device of the user. 187.The method of claims 1, 3, 4, 6, 28, 30, 31, 32, 46, 48, 49, 50, 85, 87,88, or 89, wherein the verification status of the device is identifiedin response to an external inquiry received by the device.
 188. Themethod of claims 1, 3, 4, 6, 28, 30, 31, 32, 46, 48, 49, or 50, whereinthe device includes a device interface.
 189. The method of claim 188,wherein the device interface comprises an alphanumeric keypad.
 190. Themethod of claim 188, wherein the device interface comprises anelectrical contact.
 191. The method of claim 188, wherein the deviceinterface comprises a touch screen display.
 192. The method of claim188, wherein the device interface comprises a standard electronicinterface with a computer bus.
 193. The method of claim 188, wherein thedevice interface comprises an antenna.
 194. The method of claim 188,wherein the device interface comprises a port of the device.
 195. Themethod of claim 194, wherein the port is a wireless communications port.196. The method of claim 194, wherein the port is a serial port. 197.The method of claim 194, wherein the port is a USB port.
 198. The methodof claim 194, wherein the port is a parallel port.
 199. The method ofclaim 194, wherein the port is an infrared port.
 200. The method ofclaims 1, 3, 4, 6, 28, 30, 31, 32, 46, 48, 49, or 50, wherein the deviceis portable.
 201. The method of claims 1, 3, 4, 6, 28, 30, 31, 32, 46,48, 49, or 50, wherein the device comprises a handheld device.
 202. Themethod of claims 1, 3, 4, 6, 28, 30, 31, 32, 46, 48, 49, or 50, whereinthe device comprises a computer chip.
 203. The method of claims 1, 3, 4,6, 28, 30, 31, 32, 46, 48, 49, or 50, wherein the device comprises anintegrated circuit.
 204. The method of claims 1, 3, 4, 6, 28, 30, 31,32, 46, 48, 49, or 50, wherein the device comprises a cell phone. 205.The method of claims 1, 3, 4, 6, 28, 30, 31, 32, 46, 48, 49, or 50,wherein the device comprises a PDA.
 206. The method of claims 1, 3, 4,6, 28, 30, 31, 32, 46, 48, 49, or 50, wherein the device comprises adigitized key.
 207. The method of claims 1, 3, 4, 6, 28, 30, 31, 32, 46,48, 49, or 50, wherein the device comprises a dongle.
 208. The method ofclaims 1, 3, 4, 6, 28, 30, 31, 32, 46, 48, 49, or 50, wherein the devicecomprises a subcutaneous implant.
 209. The method of claims 1, 3, 4, 6,28, 30, 31, 32, 46, 48, 49, or 50, wherein the device comprises jewelry.210. The method of claims 1, 3, 4, 6, 28, 30, 31, 32, 46, 48, 49, or 50,wherein the device comprises an integrated circuit card.
 211. The methodof claims 1, 3, 4, 6, 28, 30, 31, 32, 46, 48, 49, or 50, wherein thedevice comprises a credit card.
 212. The method of claims 1, 3, 4, 6,28, 30, 31, 32, 46, 48, 49, or 50, wherein the device comprises a debitcard.
 213. The method of claims 1, 3, 4, 6, 28, 30, 31, 32, 46, 48, 49,or 50, wherein the device comprises a security card.
 214. The method ofclaims 1, 3, 4, 6, 28, 30, 31, 32, 46, 48, 49, or 50, wherein the devicecomprises an ID badge.
 215. The method of claims 1, 3, 4, 6, 28, 30, 31,32, 46, 48, 49, or 50, wherein the device comprises a computer.
 216. Themethod of claims 15, 16, 17, 18, 34, 35, 36, 37, 85, 87, 88, or 89,further comprising the step of outputting the value of theidentification marker from the device.
 217. The method of claims 15, 16,17, 18, 34, 35, 36, 37, 86, 87, 88, or 89, wherein the identificationmarker is assigned a value representing a difference determined from acomparison between the verification data and the prestored data. 218.The method of claims 15, 16, 17, 18, 34, 35, 36, 37, 86, 87, 88, or 89,wherein the identification marker is assigned a value representing adegree of match between the verification data and the prestored data.219. The method of claim 218, wherein the identification marker isassigned a value equated with a percentage of match between theverification data and the prestored data.
 220. The method of claims 15,16, 17, 18, 34, 35, 36, 37, 86, 87, 88, or 89, wherein theidentification marker is assigned a value equated with a successfulverification when a comparison between the verification data and theprestored data results in a match.
 221. The method of claim 220, whereinthe match is an exact match.
 222. The method of claim 220, wherein theidentification marker is assigned a value equated with an unsuccessfulverification when said comparison does not result in an exact match.223. The method of claim 220, wherein the match is a proximate match andnot an exact match.
 224. The method of claims 15, 16, 17, 18, 34, 35,36, 37, 86, 87, 88, or 89, wherein the identification marker is assigneda value equated with an unsuccessful verification when a comparisonbetween the verification data and the prestored data does not result ina match.
 225. The method of claims 15, 16, 17, 18, 34, 35, 36, 37, 86,87, 88, or 89, wherein the identification marker is assigned a valuerepresenting whether any verification data was input into the devicewithin a predefined time period.
 226. The method of claim 225, whereinthe predefined period of time comprises the time since a last successfulverification.
 227. The method of claim 225, wherein the predefinedperiod of time comprises the time since a resetting of the device. 228.The method of claims 15, 16, 17, 18, 34, 35, 36, 37, 85, 87, 88, or 89,wherein the identification marker is assigned a value equated with asuccessful verification, and wherein said assigned value furtherrepresents whether an indicator was output subsequent to said successfulverification.
 229. The method of claims 15, 16, 17, 18, 34, 35, 36, 37,85, 87, 88, or 89, wherein the identification marker is assigned a valueequated with a successful verification, and wherein said assigned valuefurther represents whether an indicator was output since verificationdata was last input into the device.
 230. The method of claims 24, 26,42, 43, 44, or 45, wherein the request is inherent in receipt of theindicator.
 231. The method of claims 23, 24, 25, 26, 42, 43, 44, 45,102, 104, 105, or 106, wherein said step of evaluating the requestincludes the step of considering a level of assurance of the deviceidentifying the verification status.
 232. The method of claims 23, 24,25, 26, 42, 43, 44, 45, 102, 104, 105, or 106, wherein the request isfor the performance of a legal action.
 233. The method of claims 23, 24,25, 26, 42, 43, 44, 45, 102, 104, 105, or 106, wherein the request ispredetermined and static.
 234. The method of claims 23, 24, 25, 26, 42,43, 44, 45, 102, 104, 105, or 106, wherein the request is for access toa physical space.
 235. The method of claims 23, 24, 25, 26, 42, 43, 44,45, 102, 104, 105, or 106, wherein the request is for access to a website.
 236. The method of claims 23, 24, 25, 26, 42, 43, 44, 45, 102,104, 105, or 106, wherein the request is for access to a database. 237.The method of claims 23, 24, 25, 26, 42, 43, 44, 45, 102, 104, 105, or106, wherein the request is for access to a computer program.
 238. Themethod of claims 23, 24, 25, 26, 42, 43, 44, 45, 102, 104, 105, or 106,wherein the request is received in an electronic communication.
 239. Themethod of claim 238, wherein the request is implicit in said receptionof the electronic communication.
 240. The method of claim 239, whereinthe request is embodied in a message.
 241. The method of claims 23, 24,25, 27, 42, 43, 44, 45, 103, 104, 105, or 107, further comprising thestep of requiring verification data to be input into the device for eachone of a particular type of request.
 242. The method of claims 23, 24,25, 27, 42, 43, 44, 45, 103, 104, 105, or 107, further comprising thesteps of requiring verification data to be input into the device for aparticular type of request, but only until a said evaluation of arequest results in an approval, and then not requiring verification datato be input into the device for additional requests of such type duringa predefined period of time thereafter.
 243. The method of claim 242,wherein the particular type of request is for the performance of afinancial transaction.
 244. The method of claim 242, further comprisingnot requiring verification data to be input into the device for othertypes of requests.
 245. The method of claim 242, wherein the predefinedperiod of time comprises the time between the approval of the requestand a resetting of the device.
 246. The method of claims 1, 3, 4, 6, 7,15, 16, 17, 18, 23, 24, 25, 26, 28, 30, 31, 32, 34, 35, 36, 37, 42, 43,44, 45, 46, 48, 49, 50, 51, 85, 87, 88, 89, 102, 103, 104, 105, or 106,wherein the device includes a computer-readable medium havingcomputer-executable instructions that perform a said step of the method.247. The method of claims 1, 3, 4, 6, 7, 15, 16, 17, 18, 23, 24, 25, 26,28, 30, 31, 32, 34, 35, 36, 37, 42, 43, 44, 45, 46, 48, 49, 50, 51, 85,87, 88, 89, 102, 103, 104, 105, or 106, wherein the device includesintegrated circuitry that performs a said step of the method.
 248. Themethod of claims 1, 3, 4, 6, 7, 15, 16, 17, 18, 23, 24, 25, 26, 28, 30,31, 32, 34, 35, 36, 37, 42, 43, 44, 45, 46, 48, 49, 50, 51, 85, 87, 88,89, 102, 103, 104, 105, or 106, wherein the device includes a computerchip that performs a said step of the method.
 249. A device comprising acomputer-readable medium including computer-executable instructions thatperform the steps of the method of claims 1, 3, 4, 6, 7, 15, 16, 17, 18,28, 30, 31, 32, 34, 35, 36, 37, 46, 48, 49, 50, 51, 85, 87, 88, or 89.250. A device comprising circuitry for performing the steps of themethod of claims 1, 3, 4, 6, 7, 15, 16, 17, 18, 28, 30, 31, 32, 34, 35,36, 37, 46, 48, 49, 50, 51, 85, 87, 88, or
 89. 251. A device comprisingmeans for performing the steps of the method of claims 1, 3, 4, 6, 7,15, 16, 17, 18, 28, 30, 31, 32, 34, 35, 36, 37, 46, 48, 49, 50, 51, 85,87, 88, or
 89. 252. The method of claims 1, 3, 4, 6, 7, 28, 30, 31, 32,46, 48, 49, 50, or 51, further comprising the steps of generating adigital signature within the device using a digital signature algorithm,and then using said generated digital signature as a random number in anapplication requiring a random number.
 253. The method of claim 252,further comprising the step of using the digital signature as a randomnumber to safeguard against a replay attack.
 254. The method of claim252, further comprising the step of using the digital signature togenerate a session key for encrypted communications.
 255. A method ofdetermining a current verification status of a device that generates adigital signature, comprising the steps of: (a) receiving a digitalsignature; (b) decrypting the digital signature using a public key of apublic-private key pair; (c) for each one of a plurality of predefinedverification statuses of the device, modifying data representing amessage as a function of the predefined verification status; and (d)identifying the current verification status of the device as being thepredefined verification status for which said modified data matches saiddecrypted digital signature.
 256. A method of determining a currentverification status of a device that generates a digital signature,comprising the steps of: (a) receiving a digital signature; (b)decrypting the digital signature using a public key of a public-privatekey pair; (c) for each one of a plurality of predefined verificationstatuses of the device, (i) modifying data representing a message as afunction of the predefined verification status, and (ii) calculating amessage digest as a function of the modified data; and (d) identifyingthe current verification status of the device as being the predefinedverification status for which said calculated message digest matchessaid decrypted digital signature.
 257. The method of claim 256, whereinsaid step of calculating a message digest as a function of the modifieddata comprises calculating a hash value for the modified data.
 258. Themethod of claims 255 or 256, further comprising receiving the datarepresenting the message in addition to receiving the digital signature.259. The method of claims 255 or 256, wherein the message is predefined.260. The method of claims 255 or 256, wherein each one of theverification statuses represents a relational correspondence betweenverification data input into the device and data prestored within thedevice.
 261. The method of claim 260, wherein each verification statusdoes not reveal either of verification data or prestored data of thedevice for which the current verification status is determined.
 262. Themethod of claims 255 or 256, wherein said current verification status isassociated with a request.
 263. The method of claim 262, wherein therequest is for the performance of a financial transaction.
 264. Themethod of claim 262, wherein the request is for the performance of alegal action.
 265. The method of claim 262, wherein the request ispredetermined and static.
 266. The method of claim 262, wherein therequest is for access to a physical space.
 267. The method of claim 262,wherein the request is for access to a web site.
 268. The method ofclaim 262, wherein the request is for access to a database.
 269. Themethod of claim 262, wherein the request is for access to a computerprogram.
 270. The method of claim 262, further comprising the steps ofreceiving the request and evaluating the request based on the currentverification status.
 271. The method of claim 270, wherein said step ofevaluating the request includes the step of considering a level ofassurance of the device.
 272. The method of claim 270, wherein therequest is implicit in said receipt of the digital signature.
 273. Themethod of claim 270, wherein the request is communicated over anelectronic communications medium.
 274. The method of claim 273, whereinthe electronic communications medium comprises a computer network. 275.The method of claims 255 or 256, wherein one of the predefinedverification statuses represents an unsuccessful verification.
 276. Themethod of claims 255 or 256, wherein one of the predefined verificationstatuses represents a successful verification.
 277. The method of claim276, wherein one of the predefined verification statuses additionallyrepresents whether a digital signature has been generated by the devicesince verification data was last input into the device.
 278. The methodof claim 277, wherein one of the predefined verification statusesadditionally represents whether a digital signature has been generatedsubsequent to a comparison of verification data input into the devicewith data prestored within the device.
 279. The method of claim 278,wherein one of the predefined verification statuses additionallyrepresents whether any verification data has been input into the devicewithin a predetermined time period.
 280. The method of claim 279,wherein the predefined period of time comprises the time since a lastsuccessful verification.
 281. The method of claim 279, wherein thepredefined period of time comprises the time since a resetting of thedevice.
 282. The method of claims 255 or 256, wherein one of thepredefined verification status represents a difference betweenverification data input into the device and data prestored within thedevice.
 283. The method of claims 255 or 256, wherein one of thepredefined verification statuses represents a degree of match betweenbiometric verification data input into the device and biometric dataprestored within the device.
 284. The method of claim 283, wherein oneof the predefined verification statuses additionally represents apercentage of match between biometric verification data input into thedevice and biometric data prestored within the device.
 285. The methodof claim 283, wherein one of the predefined verification statusesadditionally represents whether a digital signature has been generatedby the device since verification data was last input into the device.286. The method of claim 283, wherein one of the predefined verificationstatuses additionally represents whether a digital signature has beengenerated subsequent to a comparison of verification data input into thedevice with data prestored within the device.
 287. The method of claim283, wherein one of the predefined verification statuses additionallyrepresents whether any verification data has been input into the devicewithin a predetermined time period.
 288. The method of claim 287,wherein the predefined period of time comprises the time since a lastsuccessful verification.
 289. The method of claim 287, wherein thepredefined period of time comprises the time since a resetting of thedevice.
 290. The method of claims 255 or 256, wherein the device is apersonal device of a user.
 291. The method of claims 255 or 256, whereinthe device is a handheld device.
 292. An electronic apparatus comprisinga computer-readable medium including computer-executable instructionsthat perform the steps of the method of claims 255 or
 256. 293. Anelectronic apparatus comprising circuitry for performing the steps ofthe method of claims 255 or
 256. 294. An electronic apparatus comprisingmeans for performing the steps of the method of claims 255 or
 256. 295.The method of claims 255 or 257, wherein said digital signature isgenerated using a digital signature algorithm, and further comprisingusing said received digital signature as a random number in anapplication requiring a random number.
 296. The method of claim 295,further comprising the step of using the digital signature as a randomnumber to safeguard against a replay attack.
 297. The method of claim295, further comprising the step of using the digital signature togenerate a session key for encrypted communications.
 298. A method ofgenerating a digital signature within a computer chip, comprisingreceiving data representing a message and generating a digital signaturefor the message by: (a) modifying the message data with additional data,and (b) then encrypting said modified message data using a private keyof a public-private key pair stored within the computer chip.
 299. Amethod of generating a digital signature within a computer chip,comprising receiving data representing a message and generating adigital signature for the message by: (a) modifying the message data byappending additional data thereto, (b) calculating a hash value of saidmodified message, and (c) then encrypting said calculated hash valueusing a private key of a public-private key pair.
 300. The method ofclaims 298 or 299, wherein said step of modifying comprises appendingthe additional data to the message data.
 301. The method of claims 298or 299, wherein said step of modifying comprises embedding theadditional data within the message data.
 302. The method of claims 298or 299, wherein the additional data comprises data prestored withinmemory of the computer chip.
 303. The method of claims 298 or 299,wherein the message data includes a field identifier corresponding to afield of data prestored within the memory of the computer chip, thefield identifier having a null value, and wherein said step of modifyingthe message data comprises retrieving the value stored in the memorylocation identified by the field identifier and embedding said retrievedvalue in the message data with the field identifier.
 304. The method ofclaim 303, wherein the memory of the computer chip in which theadditional data is stored is content searchable memory.
 305. The methodof claim 303, wherein the message data comprises XML formatting.
 306. Amethod for extracting user information from a computer chip, thecomputer chip including content searchable memory in which differentfields of data are prestored, comprising transmitting an identifier of aparticular field of data prestored within the computer chip togetherwith a null value therefor.
 307. The method of claim 306, wherein theidentifier and null value therefor transmitted to the computer chipcomprise XML formatting.
 308. A method of obtaining a random number forutilization in an application requiring a random number, comprisinggenerating a digital signature using a digital signature algorithm, andthen using said generated digital signature as the random number in theapplication.
 309. The method of claim 308, further comprising the stepof using the digital signature as a random number to safeguard against areplay attack.
 310. The method of claim 308, further comprising the stepof using the digital signature to generate a session key for secureelectronic communications.
 309. The method of claim 308, wherein thedigital signature is generated within a computer chip.
 310. The methodof claim 309, wherein the computer chip includes a random numbergenerator.
 311. The method of claim 310, wherein the digital signatureis generated within the computer chip using a private key of apublic-private key pair and a random number obtained from the randomnumber generator.
 312. The method of claim 311, wherein an ellipticalcurve digital signature algorithm is utilized to generate the digitalsignature.
 313. The method of claim 312, wherein the random numbergenerator is directly inaccessible from outside of the computer chip.314. The method of claim 312, wherein the random number generator isaccessible only by a digital signature circuit.